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FOREWORD 


This study was administered in the Flight 
Software Branch, Flight Support Division, 
MSC with B. L. Brady assigned as Tech- 
nical Monitor. Through careful planning 
and coordination, Mr. Brady, assisted by 
Mrs. Shirley Hinson, added significantly 
to our insight into and understanding of 
related MSC functions and organizations 
and, thereby, the accuracy of the study 
reported herein. 
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SECTION 1 - INTRODUCTION 


During the course of this study Computer Sciences Corporation (CSC) evaluated the types 
of data that the Manned Spacecraft Center (MSC) should automate in order to make avail- 
able essential management and technical information to support MSC's various functions 
and missions. Also, the software and hardware capabilities to best handle the storage and 
retrieval of this data were analyzed. 

MSC's requirements for new types of high volume data continue to grow, and the need to 
review and manipulate this data on a "more data faster" basis increases. It has become 
evident that a number of necessary applications to support these requirements have not 
yet been automated and that others are less efficient than desired. 

In existing systems, a large percentage of the total time and manpower available is spent 
in maintaining the data base and printing routine reports. When a user recognizes a need 
for accurate, up-to-date information in a usable form, he must take a number of steps to 
"get the problem onto the computer." Several days, weeks, or months later, the original 
poser of the problem is presented a report. Unfortunately, in many cases this report may 
contain too much or too little information for his purposes; in the meantime, his problem 
may have changed, or the response may have been received too late for the user to take 
effective action. 

Analysis at MSC discloses that man}' of the desirable features required to manage a large 
data base can be found in embryonic form in several computer complexes within the Center. 
It is clear, however, that they have not been brought together to form a single powerful 
data management tool. 

A properly implemented Data Management Supervisor (DMS) would permit the user or pro- 
grammer to quickly describe entries in a data base, to load them into the machine, to ask 
questions about them, to have the data displayed on a Cathode Ray Tube (CRT), to obtain 
hard copy reports, and to update and maintain the data base. All of these functions could 
be performed either on a production basis or interactively from a terminal in an on-line 
time-sharing mode. 

The following report develops CSC's recommendations for a unified data base and a DMS 
that provides a cost effective solution to MSC's data automation requirements. The recom- 
mendations presented are projected through a time frame that includes the Earth Orbit 
Space Station. The recommendations are based on a detailed requirements analysis, em- 
ploying data acquired through structured interviews of a wide sample of MSC personnel, 
and on in-depth studies and evaluations of existing and/or feasible data management 
systems. 
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SECTION 2 - PILOT STUDY ACCOMPLISHMENTS 


2.1 GENERAL 

In order to properly manage a complex set of missions such as those in the integrated 
manned space flight plan, availability of extensive technical and management information 
will be required. It is essential that this data be current and easily accessible to both 
project management and technical personnel for pre-mission planning, mission support, 
and post- flight analysis. 

In the past, most of this data was compiled and handled manually. Because of the rela- 
tively large number of vehicles and frequent flights envisioned for future programs, an 
automated information management system is necessary. Such automation will effect a 
more efficient operation and result in reduction of costs in the areas of program manage- 
ment, mission planning, and support operations. 

CSC was selected by MSC to perform the analysis of MSC data base requirements and 
interests. It was necessary to conduct a study to determine the types of data that require 
automation and to determine the system that can best handle the storage and retrieval of 
this information. From the information obtained by this analysis, a detailed description 
and structure have been developed of the software capabilities and data base that must be 
provided by the MSC future DMS. 

The first step in the study was to conduct personal interviews with MSC personnel. These 
interviews acquainted the various MSC groups with the goals and purposes of the study and 
extracted the data processing needs of the various groups. These interviews also provided 
opportunities to discuss with these users the capabilities of a DMS. 

Utilizing the information gleaned from the interviews, an analysis of MSC data require- 
ments was made. A list of candidate and recommended application data files to be struc- 
tured into the pilot DMS data base was compiled and presented the MSC technical monitors 
with a report on the capabilities MSC personnel wanted to see in the pilot DMS. Most of 
the selected application data files were stored in Univac 1108 data format and had to be 
converted to IBM 360 data format before they could be structured into the data base. Data 
conversion programs for these files were written. 

The NIPS and HYPERTEXT systems were chosed for the pilot DMS. A detailed analysis 
was performed of these two systems to determine the best possible means of demonstra- 
ting DMS capabilities through them. Several terminal user queries were prepared for 
each application data file. 

Demonstration of the pilot DMS was the next major step in the study. The various MSC 
groups were invited to view the pilot DMS and give their comments. Personal terminal 
console training was given to several individuals, thereby enabling them to utilize the 
two systems. 
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Throughout the project, in-depth analyses wei’e made of many generalized DMS’s cur- 
rently operating in the data processing industry. Several demonstrations of new hardware 
and software in the data processing industry were given by various manufacturers. These 
efforts were expended to ensure that the study incorporated the latest in the data processing 
technology. • 

The information gathered throughout the study is organized into this final report to eluci- 
date the requirements and additional desirable capabilities of a Center-wide DMS and data 
base at MSC. 

2.2 SUMMARY OF INTERVIEWS 

During the data base requirements study project, CSC contacted more than 200 people 
throughout MSC in order to inform them that a data base requirements study was taking 
place and to determine their interests in participating in the study. Many people in vir- 
tually all directorates were interested in participating in the data base requirements 
study. Personal interviews were scheduled with each interested MSC group. A list of 
MSC personnel who were interviewed is contained in Appendix A. 

It was recognized that most of the people at MSC who would be major users of a DMS were 
not technically oriented. They were not familiar with many of the functional capabilities 
that can be provided by a DMS. Hence, a list of questions was prepared to be used in the 
interviews. A list of these questions is contained in Appendix B. These questions were 
designed to extract the needs of each MSC group while at the same time acquaint them 
with the various capabilities of a DMS. During the interviews, CSC analysts explained the 
many capabilities of a DMS. Each MSC group representative then stated whether or not 
their area required such a capability. Some problems unique to the individual MSC gi’oups 
were also discussed in these meetings. Different ways that a DMS could help solve these 
problems were presented to the people being interviewed. Through this method the people 
who were interviewed were able to expand their concepts of how to make a computer more 
functional in their sphere of activity. 

The interviews produced considerable information including the requirements that each 
group has for a DMS and the capabilities they wanted to see in a DMS. A comprehensive 
report of the requirements for the pilot DMS was then prepared. This report was de- 
signed to aid the MSC technical monitors in the selection of the pilot DMS. 

Another accomplishment of the interviews was the identification of a cross-section of 
MSC groups that would supply data for the pilot DMS data base. Sample data was ex- 
tracted from these files and structured into the data base. 

2. 3 PILOT DMS SYSTEMS SUMMARY 

A list of currently operational DMS's that were available at no cost to MSC was given to 
the implementing contractor on August 10, 1970. This list of candidate systems con- 
tained three actual DMS systems and three textual data processor systems as follows: 
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o Data Management Systems 

NIPS 

USABAAR DMS 
INQUIRY 

© Textual Processor Systems 

HYPERTEXT 

TEXT360 

ATS/360 

A brief description of each of these systems is given below: 

© NIPS . The National Military Command System (NMCS) Support Center 
System/360 Formatted File System was developed for the NMCS by 
IBM Federal Systems Division. IBM 360 NIPS/FFS evolved from the 
IBM 1410 NIPS and can be traced back to the 1959 438L system for the 
IBM 709 and 704 computers. NIPS utilizes some older second genera- 
tion software techniques. 

© USABAAR DMS . The United States Army Board of Aviation Accident 
Research (USABAAR) Data Management System (DMS) is currently 
being used on an IBM 360 at Fort Rucker, Alabama, to maintain, 
retrieve, and display records of Army aviation accidents. USABAAR 
DMS was developed for the Army by Computer Sciences Corporation 
(CSC). The system is derived from COGENT III, a very powerful and 
highly advanced data management system developed by CSC. USABAAR 
DMS utilizes the latest state-of-the-art third generation software and 
hardware capabilities. 

© INQUIRY . The INQUIRY System was developed by the Federal Systems 
Division of IBM for the NASA Automatic Data Processing Division, 
Kennedy Space Center. This new INQUIRY System was modeled after 
the INQUIRY System of the Saturn Information Reporting System (SIRS) 
which was used by IBM for support of their contracts at Cape Kennedy. 

© HYPERTEXT . The development of HYPERTEXT was supported in part 
by a contract between Brown University and IBM. It is a general purpose 
text handling and editing system for use by writers, editors, and on- 
line readers. It takes advantage of the full capabilities of a sophisti- 
cated display terminal, the IBM 2250. The user controls the system 
by pressing keys on a functional keyboard, by pointing at the text with 
a light pen, and by entering text via the alphanumeric keyboard. The 
output portion of HYPERTEXT is actually a translator which transforms 
all of the text into a linear string of characters recognizable by the 
TEXT 360 programs. 
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TEXT 360 . TEXT360 is a text processing system with data updating, 
and page formatting capabilities. It was originally developed by IBM to 
be used to produce the reference documents of the System Reference 
Library (SRL). TEXT360 is operated in the batch mode. Input to the 
system is on free form punched cards. Output is camera-ready and is 
produced on a high-speed printer. TEXT360 updating capabilities per- 
mit the insertion, deletion, and replacement of characters, words, lines, 
and groups of lines. In addition, blocks of text may be moved from one 
place to another in a document. TEXT360's formatting capabilities per- 
mit either one-column or two-column pages. Routine functions include 
hyphenation, line justification, column headings, and indentions. More 
complex functions include the generation of horizontal and/or vertical 
lines for tables or figures. 

© ATS/360 . The Administrative Terminal System, ATS/360 is a real- 

time system that is used for data entry and text processing applications. 
ATS/360 has a comprehensive set of text processing and manipulating 
features. Data entry is from any OS data set or from a remote termi- 
nal device such as the IBM 2741 Communications Terminal. 

In order to present the most productive demonstrations possible, CSC compiled a report 
entitled "Desirable Capabilities of the Pilot Data Management System for the MSC Data 
Base October 1, 1970. " In this report factual criteria, based on CSC's own experience 
in the area of DMS's and the requirements of MSC management, were presented to the 
contract monitors to aid them in their selection of the pilot DMS. As supporting docu- 
mentation for this repoi’t, a DMS capability matrix which summarized the results of the 
personal interviews was also presented at that time. 

MSC established user requirements as the prime consideration in the selection of the pilot 
DMS. Other major considerations included cost, compatibility with other system hard- 
ware, and terminal capabilities. Trade-offs were made to approach a degree of satisfac- 
tion of all requirements. These trade-offs generally considered expediency of implemen- 
tation of the DMS. As a result of these trade-offs, the NIPS and HYPERTEXT systems 
were selected by MSC to be used in the pilot study. 

On November 2, 1970, the implementing contractor presented to MSC the results of its 
analysis of the candidate systems in the document "Program Evaluation Report. " Based 
on the implementing contractor's recommendations, MSC selected the NIPS and HYPER- 
TEXT systems to comprise the pilot DMS. CSC analysts performed a two phased analysis 
and evaluation of the pilot DMS systems. 

The fii’st phase occurred prior to the actual implementation of the systems and consisted 
of an in-depth study of all available documentation on the two systems. This study was 
oriented toward the accomplishment of three objectives: the familiarization of all options 
and procedures necessary to the physical operation of the two systems, obtaining detailed 
knowledge of the capabilities provided by the systems, and discovery of possible problem 


2-4 



CSC 


areas which could impact the demonstrations. These three objectives were accomplished 
within the time frame pi’eceding the pilot system implementation and allowed CSC to pro- 
ceed directly to the second phase of the analysis and evaluation as soon as the systems 
were operational. 

The second phase was a planned, hands-on checkout of all the operational functions suppor 
ted by the DMS's. The objectives were to develop the analysts' proficiency in operating 
the systems and to discover any idiosyncrasies of the systems that had not been uncovered 
during the documentation study. This analysis was documented in two special reports, 
"Pilot DMS Problem Areas Analysis" and "NIPS Demonstrable DMS Capabilities." 

The first report identified some of the major problems encountered and offered solutions 
to those which could be most readily corrected. The second report compared capabilities 
that were operational as of February, 1971, as opposed to those required to adequately 
demonstrate the power of the DMS concept desired by MSC personnel. 

2.4 PILOT DMS DATA 

The data base requirements study questionnaire and personal interviews established a 
benchmark to be used in the selection of the users and data for the pilot data management 
system. The basic criteria for the selection, gauged by the benchmark of both users and 
data, was that they be representative of a good cross-section of users and data types at 
MSC. A second consideration was the ease of data implementation and what features of 
the pilot system could be demonstrated with it. 

The major portion of this task involved the gathering of the information required to esta- 
blish a valid benchmark. A report was compiled, based on the findings of the personal 
interviews and CSC's past experience, entitled "Candidate Data Files and Recommended 
Data Files for the MSC Data Base, October 6, 1970. " 

The following MSC user application data files were selected for inclusion into the pilot 
DMS data base: 

© Labor Distribution 

© Accounting 

© Procurement 497 

© RMD 

© Contract Status Report 

© Budgetary Control 

« Capitalized Equipment 

© Engineering Standards Information 

© Earth Resources Text and Table Files 

© Flight Control Manpower Status 

» Skylab Program Operational Data Book 

© Statements of Work 

© Graphic Aids 
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© Catalog Index 

© Lunar Sample Natural Language Information 

© Astronaut and Clinical Patients Record 

© Advanced Spacecraft Cost Analysis 

The first ten data files were implemented into the data base for utilization by the NIPS 
system. The Skylab Program Operational Data Book and Statements of Work files wei’e 
implemented for utilization by HYPERTEXT. Seven conversion programs were written 
to convert the MSC application data in seven of the above files to IBM 360 data format 
for the implementing contractor. These data conversion activities are described in 
Appendix G. 

2.5 PILOT DMS DEMONSTRATIONS 

The personal interviews revealed that the majority of MSC groups have similar data re- 
quirements that necessitate access to a Center-wide data base. In order for the MSC 
groups to fully appreciate the power of a DMS, it was necessary for them to see one in 
action. 

Utilizing past experience in the commercial and technical data areas, demonstrations of 
the NIPS and HYPERTEXT systems were designed to enlighten MSC managers as to the 
capabilities offered by a DMS. Actual MSC data was used to prepare program queries 
for a representative cross-section of activities. By doing this, the demonstrations were 
made meaningful to the viewers and helped them to relate their data requirements to what 
a DMS could do for them. 

The demonstrations showed how data could be retrieved from the data base, sorted, 
updated and displayed to a user. Many questions were asked at the demonstrations and 
factual answers were given to all of them. In many instances, a query at the terminal 
was prepared to implement a viewer's question to demonstrate how a DMS could immediate 
ly be invoked to solve his problem. These demonstrations induced much intex’est and ex- 
panded the concept of a DMS for attendees. A list of the pilot DMS demonstrations is given 
in Appendix C. 

NIPS and HYPERTEXT were not intended to be used as production systems, but the termi- 
nal needs of some MSC groups were so great that some production use of the systems was 
allowed. It was recognized that the earth resources area could utilize the NIPS system 
on an interim basis to assist in their data queries. Upon request, the complete earth 
resources data file was structured into the pilot DMS data base. This was done and some 
queries of their data were shortened by as much as three weeks. Also a number of people 
actually entered production documents into the data base and formatted them using the 
HYPERTEXT system. 

It was made evident that the needs of each MSC group are unique in many inspects. No 
generalized DMS can completely satisfy all of these unique needs, but experts who ax-e 
experienced in DMS development can modify a general system to meet specific needs. 
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One of the most important parts of a DMS is the data base. Each data area requires a 
unique structure to make it most efficient for data queries. An analysis of each data 
area must be made by people experienced in data structuring techniques. 

2.6 CONCLUSIONS 

During the conduct of the study several conclusions became apparent. First of all, the 
availability of data to the users on a timely basis was of prime importance. This require- 
ment presented itself in a number of different forms. Timeliness, availability, and the 
capability to selectively and randomly review data was high in each user's considerations. 

Also, a large number of users are developing or considering independent solutions to this 
problem because of the lack of an integrated data base management system at MSC. Firm 
procedures will be required to prevent a proliferation of independent systems involving 
inefficiency and duplication of effort. 

Finally, the pilot DMS was effective in demonstrating that most of these information and 
data problems can be solved by an effective DMS. As a result of the interviews and dem- 
onstrations, a comprehensive list of required capabilities necessary to support users and 
desirable capabilities to further enhance retrieval and display effectiveness has been 
compiled. 
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3.1 FUTURE SYSTEM OVERVIEW 

Two categories of capabilities have been defined to support the many users’ requirements 
that were identified during the course of the study. First, required capabilities are those 
functions that are necessary to support the user by creating a data base, maintaining the 
data base, and providing optional methods for processing and retrieving information. 
Second, desirable capabilities are additional functions which further enhance the practical 
ity of the total system by orienting it more to the individual user and the solution of his 
problems. 

Both categories of capabilities were derived through the process of interviewing a cross- 
section of MSC users and then demonstrating the effects of these capabilities to them on 
the pilot system. 

The nature of MSC's data and the effect of the Skylab and Space Shuttle programs on that 
data are the dominant factors to be considered in the design of the MSC data base and 
DMS. MSC needs a DMS that will handle the data explosion that is going to occur as a 
result of the Skylab and Space Shuttle programs. These programs will be in operation 
through 1975. The DMS should be installed as soon as possible to ensure that the system 
will be productive before the Skylab experiments begin. 

Most of MSC's currently active data files are basically static in nature. The data content 
changes, but the volume normally does not expand significantly. For instance, the per- 
sonnel data file will only expand as new employees are hired. The number of records on 
the file is static in the sense that the number of employees does not fluctuate appreciably. 
The same is true of the payroll file. 

Much of the data produced from the Skylab experiments will be environmental data and 
will be in demand by many segments of the general public. This data will be dynamic 
(constantly growing in size) and will require large storage capacity and direct access 
structuring techniques. A thorough analysis of the data to be structured into the data 
base and the structuring techniques to be used must be made by personnel familiar with 
data base construction. 

A properly designed DMS would supply the data processing needs of MSC well past 1975. 
Such a system is discussed in detail throughout the remainder of this report. 

3.2 REQUIRED DMS FUNCTIONAL CAPABILITIES 

There are certain basic capabilities which must be provided by the DMS. The following 
paragraphs describe those features which are considered essential to successful opera- 
tion of such a system at MSC. 
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© Terminal and Batch Processing . At the present time, the vast majority of 
MSC computer applications are run in the batch mode. Terminal capability 
is provided on an extremely limited basis to a few MSC groups. A DMS pro- 
vides both batch and terminal processing capabilities. Terminal processing 
involves accessing of the data base fi-om either a local (hard wired) or remote 
(common carrier line) terminal. It involves the real-time processing of many 
terminal users' requests during the same time period by using the computer's 
time-sharing capability. Batch processing involves data that has been col- 
lected over a period of time and is then processed by the computer. Appli- 
cations which do not require a quick answer or which process a large amount 
of input data are normally done in the batch mode. Applications which re- 
quire quick answers will be accomplished using queries in the terminal mode. 

o Data Base Description . A DMS is useless without an effective, well struc- 
tured data base. Some means of describing data in the data base must be 
provided. This is accomplished by a data description language. The language 
will describe such things as field name, field length, record key. record 
length, file name, file structure type, data security, data type, etc. This is 
normally the first step in the implementation of a DMS. Once the module to 
describe the data base is written and installed, data files can be structured 
into it. 

o Data Access Security . Securing data at various levels is mandatory for MSC. 
Update restrictions are necessary to prevent unauthorized altering of data. 
Thus, every file will require "write" protection which restricts the capabil- 
ity to add data or modify data to only those persons authorized to alter the 
data. Some data will also have to be provided retrieval or "read” protection. 
For instance, access to an item such as a contractor's bid proposal on a 
Request for Proposal would be restricted to only a few people. Three levels 
of security should be provided, i.e. , field, record, and file. Security codes 
will be assigned to people authorized to access the data. A user's code will 
be matched against an authorized code list. If no match is obtained, the user 
will not be allowed to continue processing. If a match is obtained, the user 
will be allowed to access the data for which he has been granted access 
authorization. 

o Data Base Creation and Maintenance . The DMS must provide the capability 
to accept user files from various types of input devices (cards, magnetic 
tape, disk, etc. ) and create data files in the data base according to the data 
base description. Several structure forms should be made available, such 
as sequential structure, indexed sequential structure, hierarchical indexed 
sequential, etc. A DMS must also provide the means of maintaining data in 
the data base. Access will be provided to insert new records, modify fields 
in the existing records, and delete old records from the file in both batch and 
terminal modes. When data fields are present in many files, the field will be 
updated in all applicable files whenever an update is entered for the field. 
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Process Many Types of Data . Of critical importance to MSC is the structur- 
ing of data to minimize redundancy and reflect the required data to serve man- 
agement, administrative, and technical users. The following blocks of data 
comprise the primary types that must be pi’oeessed. 

Management Data - This commercial type data relates primarily to the re- 
sources management area. It will include such items as accounting data, 
payroll information, personnel data, procurement data, logistics data, 
scheduling and planning data, etc. This data is normally updated regularly 
according to a fixed schedule. The time between update cycles is determined 
mainly by the amount of data in the application area and the rapidity of 
changes of the data. 

Technical Data - This data is scientific in nature, i.e. , used in engineering 
calculations or used to describe technical data. Such items as lunar sample 
data and spacecraft engineering specifications would be included in this 
category. 

Library Data - This data is generally descriptive in nature, containing a brief 
amount of information about some larger item. The purpose of this data is to 
show a user identifying information available on a particular item. A user 
could, for instance, find the names of books, pamphlets, research papers, 
etc. , on particular subjects. The graphic arts file, library file, and earth 
resources file are examples of data in this category. 

Textual Data - This is documentary data. A document could be entered in 
free form into a data file and then recalled to be edited and formatted at a 
CRT terminal. The final, edited copy of the document could be printed at 
the on-line printer and sent to reproduction for processing and distribution. 
Some examples of this type of data are the Skylab Data Book and Statements 
of Work documents. 

o Simple Terminal Language with Prompting . The language provided by the 
DMS for users at a CRT terminal must be easy to learn and of a semantic 
form familiar to most users. It must prompt the user by asking questions 
and directing the sequence of entries as a user develops a query. The pur- 
pose of the simple terminal language is to enable nontechnically oriented 
people to utilize a highly sophisticated DMS. A user is asked what he wants 
to do, and when he answers the question, is told how to do it. The prompting 
part of the query could be bypassed after a user becomes familiar with the 
language procedures and requirements (see Appendix H). 

0 Short Terminal Response Time . The primary reason for a DMS and a data 
base is to provide MSC managers quick, dii’ect access to the data which per- 
tains to their operation. This makes the computer more useful as a tool for 
decision making. Data must be stractured in such a way as to facilitate rapid 
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response to queries. The terminal processing routines of the DMS must be 
highly efficient and provide an interpretive capability in order to achieve a 
short terminal response time. Appendix I provides a more detailed expla- 
nation of the required terminal processing language. 

© Update Data at a Terminal . A DMS must provide update capabilities in both 
the batch and terminal modes. The batch mode will normally be used for 
large volume updates, and the terminal mode for small volume updates. A 
manager must have the capability to add new data, change erroneous data, 
and delete obsolete data at a terminal to ensure the accuracy of output from 
queries. 

e Queries Using Multiple Search Criteria . A DMS must provide a user the ca- 
pability to state more than one data search condition. The multiple search 
criteria capability enables a terminal user to enter many different search 
conditions in one query. Quick retrieval of specific data is thus provided. 

There should be no limit on the number of search conditions that a user 
could state in one query. Boolean connectors (and, or, not) would be used 
to connect the search conditions. 

© Terminal User Selection of Displayed Data . A DMS must provide the capability 
for terminal users to display any data field in the data base. The users must 
not be limited in the data they can view, except for security limitations. In 
addition, variable output report format should be provided such that a user 
need not be concerned about formatting the data that is to be displayed. Auto- 
matic spacing between columns of data should be provided as well as a mean- 
ingful name for the headings of each column of data. The DMS should also 
provide a means of inserting dollar signs, commas, asterisks, periods, etc. , 
into the data that is displayed as the user requii’es. 

© Simultaneous Queries of the Same Data . The DMS must provide capabilities 
for simultaneous queries of the same data by users at different terminals. 
Through this capability a terminal user would not be delayed in accessing the 
data base at any time, except, of course, when the requested data is being 
updated by another user. Whenever an item of data is being updated, no user 
would be allowed to access the item until the updating action has been completed. 

® Keyword Search of Data . Many MSC groups could justify the installation of a 

DMS on this featui'e alone. All library type data files would utilize this capabil- 
ity extensively. This feature allows a user to enter a keyword at the console 
and to retrieve all the information in a file which relates to that keyword. The 
keyword may be a subject, author, mission number, site number, etc. For 
instance, all papers or books written by a particular author could be retrieved, 
all information in the earth resources file for a particular subject could be re- 
trieved, and the engineering standards for a particular subject could be retriev- 
ed. Capability to use combinations of keywords for search criteria should also 
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be provided. This capability would produce an answer set that would contain 
only data that related to all of the keywords specified in the query. 

Hard Copy of Terminal Displays . Terminal users will need the capability to 
obtain a printed copy of the contents of a CRT display. Hard copies are need- 
ed so users can take viewed results back to their desks for analysis, thus 
releasing- terminals for other users. The hard copy could also be used for 
actual production purposes. Some Xerox type devices are available for this 
purpose. Typewriters, printers, and teletypes could also be used. 

Terminal Arithmetic Operations . Data in areas such as payroll, accounting, 
logistics, and procurement require the arithmetic operations add, subtract, 
multiply, and divide. Internal decimal point alignment (floating point arith- 
metic) must be included with these operations. The DMS must provide the 
capability to perform these operations on two or more data fields. These 
data fields could be contained in the same data record, or they could appear 
in data records from different data sets. In addition, the DMS should provide 
the elementary mathematical function routines. This will enable an engineer 
or scientist to solve complex equations at the terminal. 

Sort and Merge . The DMS must provide capability to rearrange data that has 
been retrieved from the data base into a new sequence as requested by a ter- 
minal user. Data files are normally structured in one fixed sequence. If a 
sequence different from the structured sequence is necessary to satisfy a 
query, the user would designate a new sort key for the file, and a sort routine 
would then create a work file in the new sequence. The sort routine should 
have the capability to arrange data in either ascending or descending sequence 
and to sort negative numbers. The merge routine should be able to combine 
two or more data files according to a user specified sequence. 

Data Name Synonyms . Some data items are called by different names among 
the various MSC groups. For instance, one MSC group may reference a data 
item as contract number, while another group may reference the same item 
as purchase order number. Many such data similarities exist at MSC. By 
means of synonyms, different users can query an item of data using the name 
familiar to them. 

Inter- File Data Query and Update . The DMS must provide a user with the ca- 
pability to obtain data from many different files with the same query. For in- 
stance, a query may obtain an employee's name from the personnel file, his 
hours worked from a labor file, and payroll information from the payroll file. 
With this capability, data redundancy is greatly diminished. This would pro- 
vide important data storage savings since many files at MSC carry the same 
data items. If it is necessary for a data item to appear in more than one file, 
an update of this item should automatically update the item in all files in 
which it appears. 
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6 Audit Trail of Data. Updates . An audit trail is a record of the update actions 
performed on data in the data base. The DMS must provide the capability to 
keep a record of all changes made to a data file. The data base will be fre- 
quently written on magnetic tape as a backup safety precaution. If the data 
base is destroyed, it may be recreated using the latest backup tape. Audit 
trail(s) containing the update actions recorded since this backup tape may 
then be reentered in the data base. Thus, total recovery would be achieved. 

© Create, Save, and Reuse Terminal Queries . Since the terminal language will 
be a simple, English type language, nontechnical users will be able to create 
their own queries. Some queries are of a repetitive nature; therefore, if a 
user determines that he will be entering the same query repeatedly, the DMS 
should provide the capability for a terminal user to save such queries. When 
a future request requires a stored query, the user need only enter the name 
of the query, and the query would be called up and executed. Much terminal 
user time and effort will be saved by this capability. 

© Temporary Saving of Answer Sets . The answer set resulting from some 

queries may contain more data than is desired by the terminal user. He may 
want to add other search criteria to reduce the answer set data volume. On 
other occasions, a user will need to take a hard copy of the terminal display 
and analyze it before he proceeds with other queries. In such cases, he may 
wish to perform different actions on the same data set created in a previous 
query. The DMS should, therefore, provide capabilities to store a response 
to a query and allow that answer set to be recalled as input for a subsequent 
query. 

© Purge of Obsolete Data . Data on the data base can become obsolete for a 

number of reasons: The data could outlive its usefulness, it could have been 
input erroneously, data items could be marked for delete during a normal 
update run yet retained in the data base, and/or new work procedures could 
make entire blocks of data obsolete. Therefore, the DMS will provide rou- 
tines to reorganize individual data files within the database and delete all 
records that have been flagged as obsolete. 

© Editing and Validating Data . When new data is added to the data base, the 

DMS will provide a validity check and permit data to be entered into the data 
base only when certain validation criteria are met. The DMS will also pro- 
vide editing capability for both numeric and alphanumeric fields. 

© DMS Error Recovery Without Aborting . Errors can occur during processing 
which could cause system failures. This could happen due to a number of 
causes such as area overflows, division by zero, etc. If this occurs during 
DMS processing, control should be returned to the DMS, not to the operating 
system, so that the necessary core dump will be taken and an error message 
displayed on the CRT console screen. The DMS could then direct the terminal 
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user to initiate a new processing request. This capability will save consider- 
able time by allowing processing at all terminals to continue and not require 
reinitializing of the DMS. 

o Easy to Modify and Expand DMS . The DMS should be written in modules in 
order that modifications to one functional area will not impact other areas. 

A module could be modified without impairing the operation of other modules. 
Also, if other facilities were to be added, such as textual data editing or a 
graphics capability, they would be written as separate modules. The DMS 
should be written in a machine independent language. This will facilitate 
conversion or modifications when computer hardware is changed or upgraded. 
Appendix I contains a more detailed discussion concerning the DMS language. 

3. 3 DESIRABLE DMS FUNCTIONAL CAPABILITIES 

It is also highly desirable to include certain other capabilities for reasons of greater 
processing efficiency and flexibility to the user. Although these capabilities are not 
mandatory to system operation, the increased user effectiveness which they provide 
is of great value. 

© Variable Length Data Fields . Some MSC applications could greatly utilize 
the variable length data capability. At present items such as addresses, 
names, remarks, etc. are limited to specific lengths and in many cases the 
data has to be abbreviated. Conversely, much storage space is wasted by 
comments and textual type data that does not fill the space allocated for it. 

The capability to make these fields variable length would better facilitate 
MSC's data requirements. 

© Textual Document Editing and Formatting . This capability allows unedited 
documents to be input into the data base. The user then edits and formats 
the documents at a terminal to prepare them for printing. This capability 
will require a functional keyboard in addition to the terminal console key- 
board. It also provides a rapid and highly flexible means of editing documents 
without requiring the many intermediate typed versions of the document. The 
final edited and formatted version of the document can be printed using the 
on-line printer at the terminal. 

® Terminal Graphics . Many people at MSC expressed a desire to have a ter- 
minal graphics capability. The graphics capability allows a user to create 
drawings and objects on the CRT using diagonal lines and points, to display 
graphs of statistical information, etc. Areas such as engineering design, 
accounting, and graphic arts are just a few examples of applications which 
could utilize the graphics capability. 

© Remote Job Entry . This capability allows a terminal user to call up and 

execute a job stored in a system library. A job may consist of one or more 
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programs designed to perform specific tasks. The remote job entry capabil- 
ity allows a user to quickly execute prestored jobs from a terminal, thereby 
saving the time and effort required in preparing and submitting the jobs for 
the batch mode. 

© Geographic Type Data . Earth resources data needs to be reported by area 
and bj' points. Earth resources at present is utilizing the GEOREF system 
but will eventually change over to the UTM system to make earth resources 
data compatible with outside users in the way they define the coordinates of 
the area for which the data applies. 

© Access Data Using Different Languages . The use of COBOL and FORTRAN 
as programming languages is almost universal, and these are the basic 
languages utilized by MSC. Therefore, the DMS should include the capability 
to write programs in these languages. Programs written in these languages 
could also utilize DMS functions and access the data in the MSC data base. 

@ Statistical Analysis of Data . Many people expressed a desire to have the 
DMS perform some statistical analysis of their data. (This was especially 
true in some of the resources management areas. ) Statistical analysis will 
be tied in very closely to the graphics capability. Statistical analysis rou- 
tines should be callable by the DMS to provide this capability as it would 
provide terminal users with routines to obtain such items as regression 
analysis, chi squares, least squares fits, etc. , as aids in decision making. 

o Conditional Processing . This capability allows a DMS to initiate or bypass 
tasks or jobs based upon conditions encountered during processing. These 
conditions could consist of types of data processed, unusual events or errors 
encountered, or a series of required events to have taken place before a 
conditional task can be executed. This capability would not only significantly 
save computer processing time but also help to eliminate the wasted proces- 
sing of erroneous data. 

• Automatic Scheduling of Processing . Most of MSC's computer activity is 
accomplished according to a preset schedule. File update runs and report 
production are done weekly, semi-monthly, and monthly. All of these activ- 
ities could be programmed into a "scheduler" module and added to the DMS. 
The MSC applications would then be automatically pr-ocessed by the DMS 
according to the scheduling criteria specified for each application. There 
would also be provisions for a user to override the preset schedule. A ter- 
minal user could change the application schedule and cause applications to 
be immediately executed. Automatic scheduling would help produce a more 
efficient utilization of computer hardware. 

© Validate Data Base Integrity . The data base should be audited periodically 
to ensure validity of data. The audit would check data items against edit 
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criteria such as size or range limitations and type of data (alphabetic or 
numeric). If a data item is dependent on other data items, a check could be 
made to ensure the item meets all conditions imposed upon it by other items. 
An example of this might be salary, i.e. , the amount paid to an employee 
would be computed from hours worked, pay rate, overtime, income tax, 
social security tax, etc. It is also possible that portions of the data base 
could be erroneously modified or destroyed due to either hardware or soft- 
ware malfunctions. These portions could be restored from the data base 
backup tape and the audit trail records. 

© Lockout During Data Update . Two or more users could access the same 

data simultaneously. If none of the queries involve update actions, they will 
be processed concurrently. However, once an update command against an 
item of data has been issued to the DMS, all queries and other processing 
requiring this data will be delayed until the update has been completed. 

This should be at the record level, thus allowing other users to query all 
records in the data set which are not in the process of being updated. 

© Computer Transferability of the DMS . If the major portions of the DMS are 

written in a language which is virtually machine independent (such as COBOL), 
the effort to x’ewrite them will be greatly reduced should it become necessarj' 
to transfer the DMS to new computer hardware. This would result in con- 
siderable cost and time savings. The DMS would also be more easily main- 
tained if written in a machine independent language. Appendix I contains de- 
tailed discussions of this desirable capability. 

© Inverted Data Files . An inverted file capability is a powerful means of 
rapidly accessing data. Inverted files essentially consist of a series of 
different sort key index sets for any application data file. Each sort key 
index set contains records in a specific sequence and application data record 
address pointers. In a query, a user will specify the sort key index set 
which will give him the most direct access to his data. It is recommended 
that the inverted file capability be provided for the data items which are used 
most frequently in referencing or searching the data file. This is necessary 
in order to minimize the random access storage required by inverted files, 
which could be quite large. 

3. 4 REQUIRED HARDWARE FOR THE DMS 

Only nominal special hardware and configuration changes over and above those which al- 
ready exist at MSC are required to support a DMS. However, in some areas, such as 
direct access storage devices, it will be necessary to increase capacity as data files 
are added. 


© Local and Remote Terminals . The DMS hardware must provide for both 

remote and local terminal processing. Remote terminal processing requires 
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the use of common carrier lines (e.g. , telephone lines) between the terminal 
and the computer processing unit. A modem is required at each end of the 
common carrier line. A modem is a unit used to provide a data transfer in- 
terface between the computer and common carrier line (or between a terminal 
and the common carrier line). Local terminals normally utilize hard wiring 
(direct connection) from the computer to the terminal display control unit. 

Local terminals, however, should also be able to optionally utilize modems 
instead of the hard wiring. In fact, it is recommended that whenever possi- 
ble, modems be widely used for local terminals, especially where a terminal 
location is likely to be changed. This method of data communications pro- 
vides significant flexibility for placement and relocation of terminals without 
the necessity of considerable data line, adapter, and control unit hardware 
replacements or modifications. Hard wiring should be utilized sparingly and 
only for those local terminals that are almost certain not to be relocated and 
made remote (see Figure 3-1). 

Interactive terminal consoles which allow users to specify their processing 
requirements must be provided. Terminal output devices (e.g. , CRT, 
printer, typewriter) must be available to display the requested information 
that the terminal processor routines of the DMS obtain from the data base. 

A terminal keyboard/CRT with alphanumeric capability should also be pro- 
vided. MSC has many different types of data display requirements. Pro- 
vision must be made for pictorial displays of numerical, graphical, textual, 
and commercial accounting types of data. This requires a complete char- 
acter set of all alphabetic letters, all numbers, and special characters such 
as *, $, #, etc. The CRT must have the capability to display all characters 
in the chai’acter set. 

A terminal hard copy device should be provided that can produce a printed 
copy of the entire generated results of a query or the contents of a single 
CRT display screen. These devices could be typewriters, teletypes, printers, 
or Xerox copier type devices. These devices are necessary in order to give 
terminal users permanent copies of query results. Most users will need to 
review these hard copies and perform some analysis on the information. 

Without a hard copy capability, a user's analysis of displayed results would 
have to be performed at the console while the query results are available. 

This is very inefficient use of terminals. Hard copy capability will free 
terminals for subsequent users. In addition, a permanent record of the 
answers to queries could be made available to other people as well as to 
the person who performed the queries. 

Direct Access Storage Devices . The large volume of current MSC applications 
data plus the probable increase in size of some application data such as earth 
resources will require a large random access storage capacity. Earth resources 
could currently occupy approximately 200 million character positions of storage, 
if all the data they have at present were structured into the data base. This file 




Figure 3-1. Required DMS Hardware 







will multiply in size during the Skylab program. The lunar sample data is 
another application which will grow much larger in the future. Most of the 
currently active files at MSC are static and will not increase appreciably in 
size during the Skylab program. Some of the files, however, are dynamic 
and will result in a veritable data explosion. There will, therefore, be a 
need for large storage capacity in the random access storage devices. 

History tapes are normally created at year end on most of the active files, 
but these history files are not active. They are stored mainly to preserve 
a record of the previous year's activity. 

It is also necessary that a DMS provide for many types of data structures, 
the most important types being indexed sequential and hierarchical sequen- 
tial. These methods allow for direct access to specific data items and the 
chaining together of like data items. The very size of MSC files makes it 
imperative that some method of directly accessing any data in the data base 
be provided by the DMS. If only sequential searches of data were available, 
queries could take hours to complete. Each application must be analyzed to 
ensure the most efficient structure in the data base, and also the volume of 
direct access storage required to efficiently and economically support each 
application. 

© Large Core Storage Capacity . Many of the applications at MSC are extremely 
large, and some applications data areas such as earth resoui’ces will grow to 
huge proportions through the Skylab and Space Shuttle programs. Queries of 
these data files could create very large answer sets. Enough core storage 
must be available to handle such queries while at the same time allow other 
programs or jobs to execute in other partitions of core storage (multi-program- 
ming capability). A large core storage capacity would provide more rapid 
response to terminal users since a major portion, if not all, of the data in 
large answer sets could be contained in core storage and thereby be readily 
available for terminal display. In addition, many users at various terminals 
will be querying the data base simultaneously, ci'eating answer sets in core 
storage. Because of all these important factors, a large core storage will be 
required. 

3.5 DESIRABLE HARDWARE FOR THE DMS 

To make full use of expanded capabilities of the DMS, certain options should be considered. 

Through the use of additional hardware capabilities, greater efficiency and utilization may 

be obtained. 

© Terminal Console Special Features . An auxiliary function keyboard should 
be provided for text data editing and formatting operations such as data 
insertion, data deletion, paragraphing and capitalization. Once a document 
has been entered into the system the functional keyboard allows a user to 
edit the document and prepax-e it for printing. Also, many people who viewed 
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the pilot BMS demonstrations expressed a desire to have graphics capability. 

If future MSC plans are to include a graphics capability in the DMS, terminals 
should be selected that can provide vector generation. 

© Terminal Input/Output Devices . There are many printers available today 

which could be installed as hard copy devices at terminals. The volume and 
urgency of need of the hard copy output together with the economic considera- 
tions would dictate whether or not a printer would be utilized at a terminal. 
Typewriters could be used as a hard copy device at a terminal when low 
volume output is expected. 

© Microfilm . Expanded use of microfilm could reduce MSC's cost in the storage 
and retrieval of charts, drawings, photographs and text documents. For 
instance, it would take approximately 3 hours and 45 minutes to print 3,500 
pages of information stored on a reel of magnetic tape, but the same data 
could be placed on microfilm in 12 minutes. Encyclopedia Brittanica has 
developed a "Microbook Library" containing 20,000 volumes stored in two 
shoe-box sized files. There are many scanning devices on the mai'ket which 
make microfilm scanning a relatively simple task. Because of the simplicity 
of use, reduced processing costs, and conservation of storage space, many 
schools use microfilm in place of textbooks. Microfilm and microfiche (a 
type of microfilm) are now being widely used by MSC in many areas such as 
earth resources and engineering plant drawings. The use of microfilm for 
this type of data is considerably less expensive than either printing a hard 
copy or retaining the data (when possible in the data base). 

3.6 DATA REQUIREMENTS 

The broad spectrum of activities at MSC makes it a very complex facility. The DMS must 
be powerful enough to serve the data needs of all areas of MSC. As stated previously, a 
logically and efficiently structured data base is a critical part of the system. The data 
base must contain all data needed by management and technical users. 

© Management Data . Data is needed by managers to plan activities, to schedule 
work loads, to perform project analysis, and to financially control their phase 
of the MSC operations. In short, they need performance data, and this data 
would be contained primarily in the commercial applications data. A manager 
would only utilize those portions of the data that is needed to control the total 
performance of his sphere of responsibility, but this data must be readily 
accessible to him. It must also be presented in such a way so as to not re- 
quire him to spend hours analyzing it before he can formulate plans. This is 
a major reason why a thorough study must be made of MSC data, from the 
standpoint of both manager's and technical users. Someone thoroughly familiar 
with the needs of both these groups should be engaged to perform this study. 
Managers, in fulfilling their functions, will normally not utilize the highly 
technical data that is required for solving complex mathematical and engineering 
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problems. Thus scientific and engineering technical data will be utilized 
mostly by line users, engineers and scientists. Other MSC areas of technical 
data include requirements for spacecraft fuel and other expendables, configura- 
tion control data, lunar sample data, failure data, control loading and text data. 

The many technical documents produced by MSC, such as the Guidance System 
Operations Plan, should be made available for Center-wide use. This could 
be accomplished through utilization of the library retrieval, keyword capabili- 
ties provided by the DMS. 

© Static and Dynamic Behavior of MSC Data . Most of the currently active files 
in the management area are not growing appreciably in size and thus are 
static in their behavior. This data was originally designed and created to 
meet MSC's needs for the Gemini and Apollo programs, and will be used for 
future programs. A few of the data files, however, are djmamic, such as 
earth resources and other library files. These files are in a constant state 
of growth. Most of the files in the technical area that would be contained in 
the MSC data base are static, but there are some dynamic files. Lunar sam- 
ples is the largest dynamic file. It will continue growing as more and more 
tests are made on the moon rocks. Flight scheduling is a very active file. / 

Its size varies depending on mission requirements. Data behavior varies 
widely between the various MSC groups. A data base to contain the MSC data 
would have to be a well planned and carefully structured entity. 

o Impact of Space Station and Space Shuttle on Data Volume Through 1975 . Most 
of the management data which is static now should remain relatively static 
through 1975. The requirements for resources management should not in- 
crease appreciably because of new programs such as the space station and 
space shuttle. Earth resources data will be extremely dynamic, however. 

Their data is cumulative. The library data will be somewhat dynamic, too, 
since more papers, documents and literature will be published as a result of 
these programs. Technical data should also remain relatively static. Again, 
the lunar sample data will be dynamic. This is caused by the continued testing 
of the rock samples and the constant influx of data from the experiments left 
on the moon. Data for the scheduling of flight activities for the Skylab and 
Space Shuttle missions will also be in the MSC data base. It is expected that 
this technical data will have a high level of activity. The volume of this data 
is anticipated to fluctuate significantly depending on the number and complexity 
of the flight activities during Skylab and Space Shuttle missions. There will 
also be a large amount of raw telemetry data and engineering data fi’om the 
Skylab and Space Shuttle missions. Only condensed summaries of this data 
need to be considered for implementation into the Center-wide data base. 

© Data Adaptable to Data Base Type Operations . The general guideline to follow 
in implementing data into the Center-wide data base is to structure that data 
most needed by MSC managers to aid them in decision making and planning. 

Logistics, procurement, and accounting files are prime candidates. Flight 


3-14 



CSC 


scheduling should be among the first to be implemented. Since NASA will be 
playing a constantly expanding role in the environmental sciences through the 
Sky lab program, most of the environmental data should be structured into 
the data base. MSC will experience increasingly heavier demands upon this 
data as it becomes available to them. Earth resources is the major file in 
this area. The DMS and Center-wide data base are management tools to be 
used as aids in decision making. So again the guideline to follow is to struc- 
tui’e data needed to aid in decision making and planning. 

3. 7 DATA ITEM DICTIONARY 

A data item dietionar}' must be provided for MSC which contains a description of each data 
item in the MSC data base. This will enable the DMS users to become familiar with the 
content and organization of the data in the data base. This data dictionary will completely 
describe the data base by providing the necessary and pertinent information concerning 
each data item in the data base. 

There are many advantages for MSC in having a data item dictionary. The interchange of 
data among the many MSC organizations will be greatly facilitated. The development of 
standard information and data systems will also be facilitated. It will also facilitate the 
integration of MSC application systems and direct computer-to-computer communications. 
There will be a cost savings to MSC since redundant data items would be eliminated and 
time-consuming new development of data items and processing already available would 
be avoided. 

The following information will be contained in the data item dictionary for each data item 
in the data base: 

© Data Item Name . A precise, meaningful name will be assigned to each MSC 
data item. CONTRACT TYPE would be a typical item name. 

© Coded Name . The coded name for the data item will be used by terminal 

users and in writing programs for batch processing. For CONTRACT TYPE 
the coded name could be CONTYPE. 

® Item Description . The data item size, type of data (numberic, alphanumeric, 
etc.), and the decimal point position will be specified. An item description of 
"9999V9" could represent a five digit number having one decimal position. 

© Security' Code . Government security classifications of SECRET, CONFIDEN- 
TIAL, OFFICIAL USE ONLY, and RESTRICTED will be specified, when appli- 
cable, to classified data. Sensitive data that will be accessible only to certain 
persons, such as payroll and contract data, will also be assigned a secui’ity 
code. 
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o Synonym Names . Any other names by which this data item is referenced will 
be specified. TYPE OF CONTRACT could be a synonym name for CONTRACT 
TYPE. Similarly, the data item's coded name CONTYPE for file A could be 
CONTYP for file B. 

e Access Item . If a terminal user has a need to query the data base using the 
data item in a search argument, the item will be designated as an access key 
data item. 

© Edit Criteria . The edit specifications such as range and minimum/maximum 
values for the item will be included. A numeric item, for example, might 
have a valid range of only 50 - 75 inclusive. 

© Code Table Name . If an encode/decode table is to be used to translate the 
actual item value to a coded value (and vice versa), the code table name will 
be given. 

o File Name . The name of the data file containing this item. 

© Using Applications . All MSC application subsystems, such as Logistics and 
Inventory Control, which use a particular data item. 

© Description of Use . The meaning and significance of the data item to the using 
applications. 

© Update Responsibility . The MSC application subsystems and groups authorized 
to update the data item. 

© Terminal Usage . A description of any special procedures or considerations 
to be taken in retrieving, displaying and updating the data item at a terminal. 

© Item Origination . The name (or identification number) of the input transaction 
form containing the data item. Equivalent information should be supplied if 
a standard input form is not used. For data items internally generated by 
application programs, the name (or number) of the application program should 
be used. 

© Remarks . Additional information required for a complete understanding of 
the data item, such as a formula used to compute the item values. 

The Data Item Dictionary will have a complete listing of the content and organization of 
all data items in the MSC data base. There will also be functional area data dictionaries 
which contain only those data items relating to particular MSC activities. These smaller 
data dictionaries will be more meaningful and usable since only pertinent data items for 
the particular MSC activities will be in them. 
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3.8 DATA SOURCE DOCUMENT INDEX 

In conjunction with the data item dictionary, a data source document index will be provided 
which describes all input transactions and other submittal forms used by MSC and contrac- 
tors for entering data items into the data base. A description of each data source docu- 
ment and the data items created or updated in the data base by using that source document 
will be contained in the index. This index will greatly facilitate the coordination and 
integration of many data processing activities throughout MSC and thereby significantly 
reduce costs. 

The following information will be contained in the index for each MSC and contractor data 
source document: 

© Originating Source . The MSC organization or contractor responsible for 
submitting the data. 

© Originating Location . The location of the submitting organization (if not at 
MSC). 

© Input Form . The name and identification number of the input transaction form 
containing the data item. If a standard input transaction form is not used 
when entering the data item, equivalent or appropriate information will be 
included. 

© Submittal Frequency . The frequency that the data item will be submitted; one 
time, weekly, monthly, other periodic times, or as required. An exact time 
of a particular day of the week or month, when pertinent, should also be 
entered. 

© First Submission Date . The date that the data item was first submitted. 

© Transmission Format . Input transaction is contained in a punched card, 

magnetic tape, hard copy, etc. 

• Transmission Method . Method by which input transactions are received, such 
as mail, hand carry, telephone, etc. 

© Security Classification . The classification of the entire data submission will 
carry the highest classification of any data item being submitted. 

9 Responsible Application . The name of the application subsystem or group 
responsible for processing the data and entering it into the data base. 

® Coded Names and Descriptions . The coded name used in the data item diction- 
ary for each data item contained in the data source document will be listed. If 
the item description (e.g. , item length) is different than that specified by the 
dictionary, the differences should be described. 
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Some data items in the data base will be created by an application program. These in- 
ternally created data items serve special purposes, such as data record type indicator 
and accumulation or total count items. Information concerning these data items will be 
contained only in the data item dictionary. 
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SECTION 4 - SYSTEM IMPLEMENTATION 


This section discusses the major items which must be given consideration in the imple- 
mentation of a data management system at MSC. The necessary degree of management 
involvement and a projected schedule are discussed. Also, the manpower and equipment 
requirements for a suitable system are described. 

4.1 MANAGEMENT INVOLVEMENT 

In major systems endeavors, it is imperative that management participate and involve 
themselves in its achievement and success. In organizations where the computer systems 
and the data base are regarded as major resources and as important tools in achieving 
goals, management must play a strong role. An automated system, to be an efficient 
tool, requires a high degree of management. 

The prime management functions of control, scheduling, and decision making must be 
applied by MSC management throughout the phases of system development, implementa- 
tion and operation. 

© Development . Once the decision is made to implement a DMS with a Center- 
wide data base, MSC management must decide whether to acquire a currently 
operational DMS or to design and build a completely new DMS. 

The existence and use of a DMS and Center-wide data base will require a 
change in computer utilization concepts. Individual managers will no longer 
have proprietary rights to their data except in cases where the data is sensi- 
tive or classified. MSC management must instigate a mode of operation which 
will change the thinking of MSC personnel to more of a "Center activity" level, 
to a common sharing of data. 

A realistic development schedule must be established to ensure implementation 
and operational deadlines will be met. The time element is critical. MSC 
needs a DMS "up and running" before Skylab missions are flown. Flight 
scheduling for the Skylab missions could be utilizing a DMS at the present time. 
Acquiring a currently operational DMS would minimize development time and 
provide MSC with DMS capabilities almost immediately. 

Any modifications or enhancements in the DMS design must be approved by 
MSC management. They must be satisfied that any and all changes will meet 
the overall needs of MSC. 

© Implementation . A priority list for the installation of applications and exec- 
utive modules should be established by MSC management. This list would be 
based primarily on the need of the various applications for DMS capabilities. 
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An exhaustive analysis of RISC data must be made to ensure the technically 
sound structuring of data sets reflecting the required data to serve both 
management and line users. This study should be started as soon as possible 
as it will consume much time and effort. It should be completed prior to the 
implementation of the modules to define and create the data base. This will 
require ver}' careful planning and close monitoring of effort to ensure data 
availability for the data base when the modules to define and create it are 
installed. 

© Operation . MSC management must maintain control of the DMS and the data 
base. No one should be allowed to alter the contents of the data base without 
the consent and knowledge of management. An}' changes to the data base should 
be published for all interested parties. MSC groups must reorient their 
thinking to Center-wide activities rather than group activities. A control 
group of MSC managers should be formed to ensure these DMS operations 
produce the desired DMS effects. 

The DMS with a data base can be a tremendous management resource item if 
users will cooperate and use it effectively. Management must establish and 
publish procedures for the DMS. In addition, they must determine the best 
schedule for applications to be run. Batch runs and massive updates are best 
run on third shift, when the real-time use of terminals is exti’emely low. 

Management should utilize two powerful tools that are available for controlling 
the content of the data base and application system activities. These tools are 
the Data Item Dictionary and the Data Source Document Index (which are dis- 
cussed in Section 3). User's manuals for data base maintenance and DMS 
queries and operations should be published. A DMS procedures manual should 
also be published, and adherance to the procedures set by MSC management 
must be enforced by them. The best DMS and a sound, logically structured 
data base are of little use if people will not give up their proprietary interests 
and cooperate and share for the success of a larger enterprise. 

Management must also approve or disapprove future applications and file 
additions to the data base. A control group which knows the complete status 
of the data base and DMS can weigh all the factors of available storage area, 
data requirements of the new application, real-time need, etc. Individual 
users must not be allowed to make such decisions. What may be best for an 
individual could well hinder all other users. Only managers who know the 
"big picture" can thus make the wisest decisions on what applications to add, 
how to structure the data, where to place terminals, etc. 

4.2 PROJECTED SCHEDULE BY MAJOR ITEMS 

The implementation charts shown on the following pages (see Figures 4-1 through 4-3) 

indicate the manpower effort that is expected to be required to completely implement the 
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Table 4-1. Data Base Functions 


DATA BASE FUNCTION 

FUNCTIONS TO BE PERFORMED | 

APPLICATION SYSTEMS ANALYSIS 

A comprehensive analysis of current and planned MSC data processing applications must j 

be performed. The major purposes of the application systems analysis are: 


• To determine what data items should be contained in each appli- 

cation file (of the data base) and in the Data Item Dictionary . 


o. To review MSC source documents to facilitate coordination of ; 

data base input throughout MSC and to provide a more stan- j 

dardized source document format. j 


» To determine if various MSC application systems can be inte- t 

grated to form a related and coordinated network of activities 
throughout MSC. 

DATA ITEM DICTIONARY 

A dictionary of all data items that will be stored in the data base must be created and 
maintained (refer to Data Item Dictionary in Section 3 ). For ease of update and in pro- 
viding center-wide utilization, the dictionary should be stored on magnetic tape (or disk). • , 

Computer programs should be written to update and list the latest, approved version of ! 

the Data Item Dictionary for center-wide circulation and use . 

SOURCE DOCUMENT INDEX 

An index of all source documents used for creating or updating data in the data base must 
be provided (refer to Data Source Document Index in Section III). The index should be 
stored on magnetic tape (or disk). Update and report programs should be written to main- 
tain and list the Source Document Index. 

DEFINE AND STRUCTURE DATA 

The application data files that are to be structured into the data base must be defined. 
The data items contained in each application file selected must then be defined. The 
most efficient and advantageous method of structuring the data items in each file must 
be determined and then described and defined for utilization by the DMS. 

/l\ Data File Description 

Each application data file to be structured into the data base must be defined using the 
data description language provided by the DMS. 

Variable Length Data 

Provision must be made for variable length data in many of the application data files in 
the data base. The DMS routines that process variable length data should be examined 
for processing efficiency and for user requirements in defining the data . 

/% \ Data Name Synonyms 

A synonym capability will be provided by the DMS. Each data item in the application 
flies should be examined for synonym names that are currently used by various MSC 
groups . 

A\ Geographic Data 

The DMS must add the capability for defining and processing data using geographic 
coordinate positions or codes . The method of defining geographic data should be 
standardized for all application files in the data base . 
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Figure 4-2. DMS Functions Implementation 



Table 4-2. DMS Functions 


DMS FUNCTIONS 

FUNCTIONS PROVIDED BY THE DMS 

FUNCTIONS TO BE EXPANDED OR ADDED 

DATA ACCESS SECURITY 

User security codes are provided. Read/ 
write protection is provided at the file, 
record, and data item levels. 

Ease and flexibility could be improved in maintaining user 
security codes and in assigning data access security codes 
at the file, record, and data item levels. 

DATA BASE CREATION 
AND MAINTENANCE 

File create and update functions are pro- 
vided. A simple means is provided to copy 
or translate existing COBOL data files into 
the data base (the vast majority of MSC 
data that will be structured Into the MSC 
data base was created by UNIVAC 1108 
COBOL programs) . 

Capability to update other types of data must be added (e .g . 
textual and geographic). Modifications will be required for 
existing MSC application programs that will create and up- 
date data in the data base. Translating of the selected data 
files into the data base must be done . 

m 

Process Many Types 
of Data 

Management, technical and library type data 
can be processed . 

A textual data editing and formatting capability must be added 
as will a geographic data processing capability . 

[3 

Audit Trail of 
Data Update 

The changes to the data base are recorded 
only . 

The audit trail must be expanded to contain the additional 
Information required for maintaining data base integrity . 

DO 

Lockout During 
Data Update 

Capability not provided. 

The capability must be provided that will prevent other users 
from accessing any record being updated. 

REPORT GENERATION 

Comprehensive report generation routines 
are provided . 

Modifications will be required to MSC application programs 
that now provide batch reports . 

m 

Access Data Using 
Different Languages 

Data can be accessed only using the DMS 
language and assembly language . 

Capability must be added to access data using other lan- 
guages, e .g . COBOL and FORTRAN. 

ca 

Statistical Analysis 
of Data 

Only trigonometric math subroutines are 
provided . 

Flexible and expanded data analysis routines must be pro- 
vided . 

E) 

Conditional Pro- 
cessing 

Capabilities provided only at the applica- 
tion job step level . 

Processing must be able to be made conditional at all levels - 
subtask, task, function, application job step, and applica- 
tion system . 

EDIT AND VALIDATE 
DATA 

Capability not provided (user routines must 
be entered) 

A DM S encode /dec ode data item capability must be added . 
Character insertion and modification must be provided. The 
DMS must also use the specified data item criterion, e .g . 
data range in updating the data base . 

m 

Purge of Obsolete 
Data 

Capability not provided. 

Capability must be provided for authorized persons to direct 
the DMS in the purging of obsolete data . 

tn 

Textual Document 
Editing and For- 
matting 

Capability not provided . 

A textual document data processing capability must be added. 

s 

Validate Data Base 
Integrity 

Capability not provided. 

Data base validation routines must be added to ensure t fiat 
portions of the data base have not been erroneously modified. 

SPECIAL DMS 
FUNCTIONS 

Many additional functions will be provided 
by the DMS. 

Certain other highly desirable DMS functional capabilities 
must be added . 

[H] 

Easy to Modify 
and Expand DMS 

The DMS will be organized into separate 
functional component routines although 
not highly modularized. 

The DMS must be made highly modularized and, for batch 
processing functions, written in a high level language. 

G3 

Computer Transfer- 
ability of DMS 

The DMS will be written mainly in a high 
level language thereby facilitating computer 
transferability . 

Wtien the DMS is being implemented, functional modules 
should be examined to ensure capability of being transferred 
to other computers . 

G3 

DMS Error Recovery 
Without Aborting 

Error recovery routines will be provided for 
the rrajor user functions . 

Error processing must be expanded to prevent aborting due to 
any application batch processing or terminal user entry . 

mi 

Remote Job Entry 

Capability not provided. 

DMS routines to interface with the operating system must be 
provided to allow remote entry of user jobs . 

Q3 

Automatic Schedu- 
ling or Processing 

Capability not provided. 

A scheduler supervisor must be added which will control the 
running of production MSC application jobs. 

OTHER DMS FUNCTIONS 

Capability not provided. 

Provision should be made for other desired DMS functional 
capabilities not provided by the DMS. 

USER TRAINING 

A DMS programming language and procedures 
manual will be provided with the DMS. 

Training classes and DMS consultation must be provided 
to familiarize users with the DMS programming language 
and procedures for accessing the data base. 
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Figure 4-3. Terminal Functions Implementation 














Table 4-3. Terminal Functions 


TERMINAL FUNCTIONS 

FUNCTIONS PROVIDED BY THE DMS 

FUNCTIONS TO BE EXPANDED OR ADDED 

TERMINAL USER 
LANGUAGE 

A terminal language will be provided by the 
DMS. 

The terminal language functions should be expanded and 
simplified. 

© 

Simple Terminal 
Language With 
Prompting 

A terminal language with some user prompting 
will be provided . 

The terminal language should be simplified for non-technical 
users with additional meaningful user prompting. 

© 

Short Terminal 
Response Time 

The DMS terminal processor will provide 
an adequate terminal response time . 

The DMS terminal processor routines should be examined for 
possible processing efficiency improvements. 

QUERY AND EXTRACT 
DATA 

Capability to query and extract data will be 
provided . 

Query and extract capabilities must be expanded. 

l© 

Keyword Search 
of Data' 

Capability not provided, ft can only be 
simulated through use of many search argu- 
ments . 

A keyword search capability must be added. 


Arithmetic Opera- 
tions 

An arithmetic operations capability will be 
provided by the DMS . 

This capability should be expanded to allow complex ter- 
minal manipulation of data items and literals. 

© 

Queries Using 
Multiple Search 
Criteria 

Capability is provided. 

This function should be examined for simplicity of use and 
efficiency of the processing routines. 

© 

Simultaneous Queries 
of Same Data 

Capability is provided. 

This function should be examined for any system problems, 
caused by many simultaneous users and for efficiency of I 

the processing routines . 

0 

Inter-File Query 
and Update 

Limited capability is provided for selecting 
data items in several files for query . Inter- 
file update of data items is not provided. 

Capability must be expanded to allow any user desired data 
items in the data base to be specified for queries . An inter- 
file update of data capability must be added. 

© 

Create, Save and 
Reuse Queries 

Capability to create, save, and reuse com- 
plete queries (unmodified) will be provided. 

Capability must be provided to store complete and partial 
queries; retrieve and then modify, insert, and delete entries 
in any query before it is processed. 

DISPLAY DATA 

Capability is provided. 

The display data function must be expanded. 

© 

User Selection 
of Displayed Data 

Capability is provided for selecting data 
items from several files for display. 

User specified display formal flexibility must be expanded, ' 
and the capability added to display any user selected data 
items from the data base . 

© 

Sort and Merge 
Data 

Capability is provided for displaying data 
sequenced by any combination of data items 
within only one file . 

This function should be expanded to allow user displays to 
be sequenced by any combination of data items in the data 
base . Processing efficiency of the sort 'merge routines 
should also be examined . 

© 

Hard Copy of 
Displays 

Capability is provided for a user to specify 
hard copy of one CRT page or the entire 
snswer set to the major output devices (e .g . 
CRT, printer, teletype). 

Capability should be extended to allow user selection of a 
series of CRT page displays to any output device used at 
a termina l . 

i 

© 

Saving of Answer 
Sets 

Capability is provided to temporarily save the 
entire answer set . 

Capability should be extended for a user to temporarily or 
permanently save portions or the entire answer set . 

© 

Inverted Data File 

Capability is provided to directly access any 
data file record by using multiple data item 
indexes (inverted files). The inverted files 
cannot be easily modified or expanded. 

Flexibility must be added in the creating and maintaining of 
inverted files in order to include only those data items 
frequently used for search criteria in queries . Processing 
efficiency of the query routines that utilize inverted files 
must also be examined. 

© 

Graphics 

Capability not provided. 

A graphics capability should be added. 

UPDATE DATA 

Capability is provided to update data in 
only one file at a time . 

An inter-fde update capability must he added. Capability 
should also be provided for update routines to be automatically 
called up to process and edit any modified data items . 

OTHER TERMINAL 
FUNCTIONS 

Capability not provided. 

Provision should be made for other desired terminal functional 
capabilities not provided by the DMS. 

USER TRAINING 

A terminal user's manual will be provided by 
the DMS. 

Training classes and terminal user consultation must he pro- 
vided to familiarize users with terminal operations . 
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DMS, structure the MSC application data into the data base, and train MSC personnel in 
the most advantageous procedures for utilizing the DMS and the data base. 

The numbers shown above the arrows reflect the expected manpower that will be required 
to install the data base and DMS functional capabilities. The manpower figures shown for 
the first month of each function being implemented will continue either to the completion 
of that function or until a new manpower figure is shown for the function at a later time 
in the chart. 

Functions to be implemented were assigned numbers and enclosed in triangles, squares, 
or circles underneath the implemented functions arrow lines. The assigned number for 
each function is explained in a legend at the bottom of the chart. Each function is then 
described in detail in the pages following the charts (see Tables 4-1 through 4-3). 

The estimated implementation manpower figures are based on MSC obtaining a DMS with 
only those functional capabilities as explained in the detailed descriptions following the 
implementation charts. It is quite possible that some of the DMS functional capabilities 
that are expected to require manpower effort for implementation will be already fully 
operational in the DMS obtained by MSC. In this case, the manpower loading for any fully 
implemented function should be deleted from the charts. This would reduce the required 
manpower for implementation of a fully operational DMS and data base. 

The estimated manpower loading shown in these charts would not necessarily be all addi- 
tional required manpower. The comprehensive functions provided by the DMS will un- 
doubtedly eliminate the requirement for some data processing functions that are now being 
performed manually. The personnel involved in these manual data processing operations 
that are made unnecessary would be reassigned to the data base and DMS functional areas. 

4.3 ESTIMATED IMPLEMENTATION MANPOWER REQUIREMENTS 

The manpower required to install and modify a currently operating DMS will be much 
less than that required to write and implement a newly designed DMS. There will also 
be manpower requirement differences depending on the capabilities provided in the 
acquired system and the language in which it is written. Refer to the charts under 
Projected Schedule by Major Items for Data Base and DMS implementation manpower 
requirements. 

An effective DMS will allow MSC to reduce the number of application programmers and 
analysts required. Through the use of simple, English type terminal language, many 
program requests which normally would be routed to a contractor's programming group 
will be done by a nontechnical person at a terminal. Thus contractor manpower needs 
will significantly reduce. 

As functional modules of the DMS become operational, MSC personnel in the application 
areas being installed must be trained in the operation of the DMS on the computer. 
Training of personnel wall be a recurring requirement since each application area would 
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require its own people trained to effectively utilize a terminal. The best approach would 
be to train them just before their application is made operational. Retraining will also 
be required as more capabilities are added to the system. 

4.4 IMPLEMENTATION RECOMMENDATIONS 

The most efficient approach in designing a DMS is to make it modular in nature. The 
DMS will basically consist of logic modules to define, create and maintain the data base, 
sort and merge data, retrieve data and report data. The DMS should be machine indepen- 
dent, not totally tied to one computer type. It should be written in a language which 
could be easily transferred to different computer hardware. This is necessary because 
technology is rapidly producing newer, more efficient data processing hardware which 
MSC may wish to install at some future date. 

Logic modules to handle the needs of the various applications such as earth resources, 
logistics, procurement, etc. , will be written separate^ from the DMS but will utilize 
the capabilities of the DMS in performing their functions. These applications modules 
will be programmed and installed according to the applications priority list. Building 
a DMS in this fashion will reduce conversion costs when new computer hardware is 
installed. It will also enable functional modules of the DMS to be used as they are 
installed and made operational. It will also serve to test and check out the DMS under 
an operational environment. 

As discussed previously, manpower requirements will be less if a currently operational 
DMS is acquired and modified to fit MSC's needs. Acquiring a system will shorten the 
time necessary to install and check out the DMS. This will enable MSC to quickly 
utilize the capabilities of a DMS. Some systems are public domain, so it is quite 
probable MSC could install one of these s3 r stems simply for the cost of any modifica- 
tions which would have to be made. Acquiring a currently operational DMS will shorten 
installation time, reduce manpower requirements, and x’educe the overall cost of installing 
a DMS. 

A careful analysis of data must be made to determine which data is to be placed into the 
data base. This analysis will consume a significant amount of time, but it is necessary. 
The analysis of data could begin before any programming is done on the DMS. In fact, 
some data analysis was performed for the pilot study which will be beneficial for the 
larger data analysis to construct the Center-wide data base. 

The major emphasis in construction of the DMS is to first install the logic to define the 
data base. Next, the logic to create the data base must be installed. Most of the initial 
effort must be in these two areas. Preparing the logic modules to maintain the data base, 
sort data, retrieve data and report data could be done simultaneously. Once the logic to 
define and create the data base is installed, data files can be structured into the data 
base. Therefore, data analysis, coding and keypunching, if needed, could be done while 
the logic to define and create the data base is being written. 
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Once the data structuring logic is determined for the data base, the applications can be 
structured and placed into the data base. Some data may be structured directly from 
current tape files. Other data may need to be keypunched and entered from cards. Each 
application will require slightly different handling. The most advantageous structuring 
for each file must be determined. Some files may require an indexed sequential and/or 
hierarchical structure (see Figures 4-4 and 4.-5) while others may best function utilizing 
a simple sequential type structure. Each file will have its own unique requirements. 

Data files should be structured and placed in the data base according to the applications 
priority list. Earth resources should be considered for one of the first applications 
installed into the DMS. Their data storage needs are large and growing daily. A 
veritable explosion of data will be experienced in this area as a result of the Skylab 
Program. Coupled with this is a growing awareness by the public of the existence of 
this data. Their demands upon this data will grow very rapidly over the next few years. 
Flight scheduling should be considered high in priority. This is a very active area and 
has a critical need for DMS capabilities. Logistics and procurement applications must 
also have a high priority. 

4.5 USER EDUCATION 

A DMS requires an extensive user educational program. Users must be trained in the 
use of the DMS language, terminal language, terminal operations, data item dictionary, 
source data document index, DMS computer operations, and DMS batch operations. 

Users should receive the training they need to properly utilize the DMS as a tool to 
fulfill their job functions. Training manuals, classroom teaching, and private consulta- 
tions with users must be provided. 

© DMS Language . All analysts and programmers should receive training in 
the use of the DMS language. This will be used mainty for jobs oriented 
toward batch processing and will require a technical programming back- 
ground. Through the use of the DMS's standard functional routines and the 
high level DMS language, applications systems and programs will be written 
more rapidly and thus be put into production more quickly. 

© Terminal Language . Analysts, programmers and nontechnical persons who 

have a need to view data in the data base must be taught the use of the terminal 
language. Analysts and programmers could utilize terminals for system and 
program testing while the nontechnical users would utilize the terminals for 
quick answers to everyday procedural problems. 

This language should be simple, easy to learn, and of an English type 
language. It should be designed with prompting to assist a user with query 
input. 

© Terminal Operations . Everyone who will be using terminals to query the 
data base will need instruction on how to operate the terminal hardware. 
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Figure 4-4. Example of Hierarchical Structure 







INDEXED SEQUENTIAL STRUCTURE 
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Figure 4-5. Example of Indexed Sequential Structure 



They need to know how to open a terminal for processing, the function of each 
key on the keyboard, and how to shut down a terminal. A manual explaining 
terminal operations should be placed at each terminal. Training in this area 
should include some "hands on" experience at the terminal itself. 

Data Item Dictionary . A data item dictionary is a necessary tool for all 
terminal and batch users of the DMS. They will need to know names applied 
.to data, the data type (numeric or alphanumeric), the meaning of a piece of 
data (what it is used for), file name containing the data, record keys, etc. 
This knowledge is necessary to query data in the data base. A condensed 
version of the data item dictionary containing just the information necessary 
to make queries would be placed at each terminal. 

Data Source Document Index . There will be times when the DMS users will 
need to know the document from which certain data items are taken. These 
users should be taught how to use the data source document index to obtain 
this information when it is needed. 

DMS Computer Operations . Only computer operations personnel need to 
receive this training. A DMS with a Center-wide data base will require 
special handling in computer operations. Applications processing will take 
piace in a real-time environment with simultaneous multi -job processing. 

This will result in more throughput from the computers and a much faster 
type of operation than in the past. Knowledgeable, alert operators will bo 
required to ensure the most efficient utilization of computing hardware. 

DMS Batch Operations . Analysts and programmers will need to be thoroughly 
familiar with the DMS batch operations. Much of the applications systems 
output will come from the batch mode. Periodic reports, massive file up- 
dates, etc. , will be done in the batch mode. The programmers will be 
writing the bulk of applications systems and will need this knowledge to 
more efficiently utilize the DMS and all of its inhei'ent capabilities. 
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SECTION 5 - SUMMARY/RECOMMENDATIONS 


During the course of the study, it became apparent that techniques must be implemented 
which would make information processing at MSC more responsive to the users' require- 
ments. A very effective solution to this problem is the implementation of a Data Manage- 
ment Supervisor (DMS), coupled with a comprehensive and well structured data base. 

One of the prime advantages that accrues from the use of a DMS is the increase of capa- 
bilities offered the user in solving his information problems. Other advantages are in the 
areas of improved programming techniques, certain cost reductions, and improved proces- 
sing efficiency. 

5.1 DATA MANAGEMENT SUPERVISOR (DMS) 

The advanced techniques of file management and retrieval made available by a DMS will be 
required by^ MSG to support the fever -decreasing demand- for information. • 


Standardized program routines, such as report formatting, data editing, data retrieval, 
"add' Updating - , invoked by'the "a's'e t" \Vri f afford a sysle'm’dhore dnfented'towards dnhanclhg' 
responsiveness to many different types of users. For the programming staff, ease and 
quickness .of program maintenance and modification will be a. significant factor. 


Through the earth orbital program and its related scientific applications such as meteor- 
ology, earth resources, and earth physics, NASA could produce more pertinent data on 
our environment; the movement of the earth, land, and ice masses; and various weather 
models than heretofore imagined. This massive volume of data will require better than 
existing techniques for its maintenance and world-wide dissemination. 


Flight scheduling is one of the most active areas at MSC. It will become even more active 
during the Slqylab and Space Shuttle programs. The data files required to handle flight 
scheduling are large. When changes to the flight schedules are made, rapid access to the 
data on the files is necessary. One minor change could cascade into many changes through- 
out the entire schedule. Real-time, direct access to the data is especially mandatory 
while the missions are in progress. 


The earth resources area has the potential of becoming one of MSC's largest and most ac- 
tive areas. Millions of items of data will be structured into the earth resources data set 
in the data base. This data is available to the general public and the demand by the public 
on this data will expand. Already large educational institutions, research foundations, 
and industry have made requests for this data. 

All of these areas have a need for a DMS at the present time. This need will become even 
more critical as MSC efforts are phased out of the Apollo program into the Slcylab program. 
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Some MSC groups such as earth resources, flight scheduling, and logistics have an 
urgent need for a DMS. Though the needs for a DMS are greater in some groups than 
in others, practically all the groups who were interviewed or who attended the demonstra- 
tions expressed a desire for MSC to install a DMS with a Center-wide data base. A few 
MSC groups even used the pilot DMS to do some of their production work. 

A modular concept should be used in designing a DMS. Separate modules would be written 
to perform the various functions such as defining the data base, creating it, maintaining 
it, sorting data, retrieving data, and reporting data. Whenever changes to any area are 
required, a new module with the changes would replace the old module. Also the various 
MSC applications would be written as separate modules and would simply enter the DMS 
when necessary to utilize the capabilities provided by the DMS. 

Timewise and costwise, a machine semi-independent language for the DMS is an extremely 
desirable design feature. The major functional modules of the DMS should be written in 
a high level, machine independent language such as COBOL. By doing this, a change 
in computers would require only minor modifications to the DMS. Refer to Appendix I for 
a detailed discussion of the DMS language. 

5.2 PRACTICALLY STRUCTURED DATA BASE 

It is of critical importance that the data sets within the data base are uniquely structured 
to take full advantage of the capabilities provided by the DMS in meeting users' 
requirements. 

It would be unreasonable to assume that all data could be included in a data base. The 
capacity to store this volume of data would be unrealistic plus such a volume would down- 
grade the effectiveness of any system. 

It would also be unreasonable to assume that all of the data which is stored could be 
structured and stored in the same manner. There is a difference between data and in- 
formation; therefore structuring of files must be versatile enough to be highly responsive 
to many different types of information requirements. 

By fully appreciating the importance of data base structuring and the effect it can have 
on the effectiveness and practicality of automated systems, MSC can progress more 
efficiently to the solution of its information sciences problems of the future. 

5.3 MANAGEMENT INVOLVEMENT 

In a major systems endeavor, it is imperative that management participate and involve 
themselves in its achievement and success. In organizations where the computer systems 
and the data base are regarded as major resources and as important tools in achieving 
goals, management must play a strong role. An automated system, to be an effective 
tool, requires a high degree of management involvement. 
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The prime management functions of control, scheduling, and decision making must be 
applied by MSC management throughout the phases of system development, implementa- 
tion, and operation. 

5.4 PROGRAMMING 

A powerful programming language will be provided by the DMS. This language will enable 
programmers to quickly design and implement complex application systems that would 
normally take considerably longer to implement. This programming simplicity provided 
by the DMS results from the high level, functional type processing that can be utilized by 
a DMS programmer. To illustrate the power of the DMS language, an analogy could be 
made to the construction of a house. Most houses are built one piece at a time, but a 
house can also be prefabricated. This is the modular concept (see Figure 5-1). Through 
utilizing and combining highly advanced and efficient program modules, a DMS programmer 
can quickly design and implement very sophisticated and efficient application systems. 

A great advantage provided b3' the DMS is the vast library of specialized program module 
routines that can be utilized by the DMS programmer. These specialized functional modules 
include routines such as file creation, file update, editing, encode/decode table lookup, 
statistical analysis, file sort and merge, data extraction, report formatting, report gener- 
ation, graphics, etc. 

There are also other important programming advantages provided by a DMS. Most of the 
MSC applications can be designed and oriented to utilize the DMS terminal capabilities. 

File maintenance and report generation can be quickly and easily performed utilizing the 
simple, English type terminal language provided by the DMS. This language, being 
specially designed for use by nontechnical persons, allows managers and staff assistants 
to rapidly update data and receive individually oriented, highly complex and meaningful 
reports . 

Application program modifications and expansion can be made easily and quickly through 
utilizing the high level DMS programming language. The DMS programmer can invoke 
the DMS functional modules to perform the desired processing. 

The DMS programmer could also include and call up program routines that were written 
in other programming languages, such as COBOL. This capability will allow utilization 
of currently existing MSC program modules and routines by merely specifying their name 
in a DMS program. Current MSC update and report generation application programs 
could therefore be used as is, except for the minor modifications that must be made to 
remove the processing of any redundant data. The DMS will also allow programmers to 
continue writing new application programs in other languages, such as COBOL, if so 
desired. It is recommended that programmers become familiar with the DMS language 
in order to take advantage of its much more powerful and comprehensive capabilities. 
Programs written in another language could, however, utilize the special function modules 
provided by the DMS. 
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Many programs will be written at terminals using the DMS terminal language. Once 
these are checked out and are producing successful output, they could be stored in the 
system libraries. They can then be executed by simply calling up the program name. 

The DMS will also contain a routine to permit a terminal user to type in program changes 
before a program is . called up. 

The DMS should generate program modules that have basically a common design format 
for the same DMS processing function (see Figure 5-1). The design format will be highly 
advanced and produce efficient processing routines. Thus for each specified DMS language 
processing function, the DMS programmer knows almost precisely the program logic that 
will be generated to perform that function. For example, the DMS sort function would 
always generate the same logic design for sort processing, regardless of the particular 
data file that is being sorted. Similarly, a file update will contain another logic design 
format that will be common to all file update routines. 

The standardized program routines that will be generated by the DMS have many advantages. 
First, it allows each processing function to be designed to produce the most efficient 
processing. Second, it allows changes to be easily made to the generated programs. It 
also provides for simple, standardized documentation, since the same processing func- 
tion would always generate basically the same program design logic. It also greatly 
facilitates modifications or expansions to programs written by another programmer. 

5.5 PROCESSING EFFICIENCY 

A DMS will provide MSC personnel with a real-time data access system which provides 
rapid retrieval of data from the data base. The retrieval time will depend on a number 
of factors such as query complexity, size of the data files being queried, search criteria, 
file structure, output requirements, other jobs running simultaneously in a multi -job 
environment, etc. Currently, most requests for computer runs require at least a 12- 
hour turnaround time which means a requestor's job can be processed overnight and 
returned to him the next morning. With a real-time data access system, each user will 
have immediate, direct access to the data in the data base. 

Simplified program documentation will result for several important reasons. First, 
the DMS processing functions are highly modular. The DMS language provides a com- 
plete processing routine when a DMS function (and the few associated parameters) are 
specified (see Figure 5-1). For application system flow charts, the use of these DMS 
processing functions greatly simplifies the understanding of the entire application system. 

Secondly, the DMS generates a standard program module for each DMS processing func- 
tion specified by the user. For detailed flow chart documentation the same basic detailed 
logic design can therefore be used for any given DMS function, such as file update. The 
basic detailed logic flow charts for each different DMS function will be supplied to MSC 
users as part of the standard DMS documentation. 

Most of the programs in the DMS applications modules will utilize the capabilities of the 
DMS. Since the documentation will have been written for the DMS, no new documentation 
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Figure 5-1. DMS Batch Processing 







is required for those parts of the applications which utilize the DMS capabilities. This 
documentation will be standard in all programs. MSC's documentation standards will 
be more perfectly adhered to, and the time involved to prepare documentation will be 
shortened. Consequently, program utilization and understanding will improve as a 
result of standard documentation. 

The modular and standardized design of the MSC application programs generated by the 
DMS will facilitate the integration of these applications into operational systems. Many 
functions required by applications systems will now be performed by the DMS. This 
includes such things as data editing and validation, file creation, data retrieval, report 
formatting, etc. So applications systems will now be much smaller after the DMS is 
installed, and programs will be written to utilize the capabilities of the DMS thus miking 
the programs much smaller. 

There must be time spent in analyzing the existing systems and data files to determine 
the best way to integrate the present environment into the DMS. Some systems could be 
combined with others, as could some data files. 

Many of the files at MSC contain obsolete data and data which is also contained in other 
files. Obsolete data is information which is carried on current files but is never used. 
They were important items when the systems were developed but have ceased being func- 
tional or needed by the systems. This data could be completely eliminated, or could be 
saved as historical data if a potential need for it would exist at some future date. Only 
currently active data should be structured into the data base. 

Some items exist on many different MSC application data files. This redundancy of data 
frequently results in these items having different values and contents in the various 
application data files throughout MSC. Most of these items need only appear once in the 
data base. Thus the redundancy of data would be greatly reduced. 

5.6 USER BENEFITS 

Analysis has shown that numerous files and redundant data in other files will be eliminated 
by the implementation of a common data base. This will result in a reduction of applica- 
tion programs that perform the same functions. The overall effect will be an appreciable 
reduction in duplicate software activities. 

The design and construction of the data base will aid the various MSC groups in increased 
communications and coordinated activities. Proprietary rights to a group's data will 
virtually disappear unless the data requires security protection. 

The expanded capabilities can be categorized into three broad areas; real-time processing, 
control of applications and data, and more efficient utilization of hardware and software. 

Real-time processing provides a multitude of expanded capabilities , the most important 
being the man/machine interaction via a remote or local terminal. 



MSC management, through having immediate access to comprehensive data concerning 
many facets of MSC activities will increase management visibility of the many MSC 
efforts and activities. 

Once the DMS is installed MSC managers will no longer be required to wait from 12 to 
24 hours for turnaround on their computer runs. The DMS will provide them with im- 
mediate, direct access to the data base. 

It is of prime importance to MSC that any classified and sensitive data be protected from 
unauthorized access. Data access security protection will be one of the first DMS func- 
tional capabilities implemented. This will ensure that data security protection will be 
provided before any functional portions of the DMS are released for MSC utilization. 

The automatic scheduling of production applications will be another significant capability 
provided for MSC. The operational schedule of execution for MSC applications could be 
specified to the DMS. Special override conditions would also be provided. This capa- 
bility would be of considerable assistance to computer operations in the scheduling of 
weekly, monthly and year-end computer runs. 

5.7 COST 

Greater throughput per computer dollar will result from the installation of a DMS. The 
many data structuring techniques provided by the DMS will reduce the amount of time to 
retrieve data, thus allowing computer applications to be processed much more rapidly. 
Reduced processing time means reduced costs. 

It is very difficult to estimate the dollars saved by providing real-time access to data. 

In the past managers have had to wait 12 to 24 hours, or even longer at times, for. com- 
puter run results. In many cases the activities of many people were curtailed or greatly 
hindered by the wait. This is especially true of programmers who have to wait for turn- 
around on program tests. 

Costs are greatly reduced through utilization of the simplified high level programming 
capabilities provided by the system. Costs will also be reduced through standard pro- 
cedures for computer operations for all phases of the DMS comprehensive activities. 
Another important cost savings will result from the standard program logic modules 
generated by the DMS. Program standardization also greatly simplifies program docu- 
mentation since each generated logic module will have the same basic logic design format 
for any given system function. 

The key to reduced program maintenance costs is the ease of modifications that can be 
made at two different program levels. At the highest level, using the simple yet powerful 
DMS programming language, program modifications and expansion can be easily imple- 
mented. At another program level, using the standardized logic modules generated by 
the DMS, program maintenance is also facilitated. This results largely from the fact 
that the basic logic design format would be known for each of the generated MSC 
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applications functions, (e.g., sorting or report generation). Also important is the ad- 
vantage of having the generated application programs written in a high level language, 
such as COBOL. The high level language greatly facilitiates program modifications and 
expansion at the generated application program level. 

Having more powerful tools to work with, the productivity of a programmer utilizing DMS 
capabilities will greatly increase. In addition, through the use of high level languages 
and with standardized programming techniques utilized, there will be little difficulty for 
a programmer to modify or expand programs designed and written by other programmers. 
This program transferability previously has been a serious problem throughout the com- 
puting industry. 

An MSC application module (e.g., logistics, capitalized equipment) may be developed and 
implemented in a much shorter time through utilizing the powerful DMS capabilities. The 
cost savings to MSC is therefore not only in the reduced amount of application program 
design, implementation, and maintenance, but also in the reduced lead time required for 
new application implementation. 

MSC has an enormous number of application data files which require file maintenance 
programs in order to keep the data current and valid in these files. As shown above, the 
powerful DMS language capabilities greatly reduce programming time and effort. A 
tremendous file maintenance cost savings will be achieved for MSC through utilization 
of the DMS programming languages. The size of the data files and the number of the 
application data files will also be reduced since redundant data could be minimized in the 
MSC data base. 

The major portions of the DMS itself will be written in a high level language such as 
COBOL. This high level language programming of the DMS will allow the DMS (and 
MSC applications programs written in high level languages) to be transferred from one 
computer to another with only minor modifications required and wall result in a tremen- 
dous cost savings to MSC . 

Similarly, if a different operating system for the computer were released by the computer 
manufacturer and installed at MSC, there would be relatively little impact on the DMS 
system modules or on the MSC application programs utilizing the DMS functions. This 
advantage results from the modular design and high level language programming capabi- 
lities utilized by the DMS. 

There will be an initial cost for implementation of the DMS, data base, and hardware 
configurations. This cost, however, will be minimized by the considerable long range 
savings provided when the DMS is functionally operational. The powerful and compre- 
hensive additional data processing capabilities provided by the DMS will also offset the 
initial cost. 
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Initial training of MSC personnel will be required to utilize the DMS functional capa- 
bilities. This training will be needed primarily in the use of the terminal language and 
the, high level DMS language. Due to the simplicity of these languages and the use of 
prompting, only a small amount of training will be required to enable MSC personnel to 
use the system. 

5.8 SUMMARY 

In summary, it is recommended that NASA MSC: 

• Implement in a time frame of one year or less a Data Management System 
that either embodies the required capabilities as set forth in this study, or 
may easily be enhanced to include the required capabilities. 

• Establish an applications/data file priority list for implementation that is 
compatible with lead times of known MSC missions. 

• Immediately start analyzing and structuring data sets which realistically 
reflect MSC requirements. 

• Develop a Center-wide data element and function dictionary which would be 
used as a management tool to control system quality, and as a user tool to 
obtain maximum responsiveness. 

• Approve and implement acquisition of long lead hardware required to support 
the DMS and data base. 

0 Develop an MSC wide management plan that will have the effect of recognizing 
the data base as an on-going MSC resource, and thereby delegate its control 
to team management decisions rather than individuals and unilateral actions. 

0 Select a contractor thoroughly familiar with commercial -type processing, all 
aspects of DMS logic, and complex and varied data base construction to imple- 
ment the MSC DMS. Contractor familiarity and understanding of user require- 
ments are essential factors to be considered. 
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Mail 

Code 

Division 

Persons Interviewed 

BB 

Institutional Resources and Procurement 

William P. Kelly, Jakey Wood, 
Parker Carroll 

BB12 

Institutional Resources and Procurement 

Bob Soens, D. R. Hendrickson 

BD22 

Research and Development Systems 

Dave Friis 

BD23 

Research and Development Systems 

Clyde Lourimore, Rudolph Willman 

BE 

Management Analysis and University 
Programs 

Leslie Sullivan, Bill Larsen, 
Charlie Buckel 

BF 

Logistics 

Jim Frizzell, George MacDougall, 
Bob Boyd, Bill Bennett, Bill Calhoun 

BM 

Management Services 

Earl Rubinstein, Stan Jacobsen, 
Roy Magin, A1 Bradley 

BM2 

Management Services 

Harold Davis, Carol Childs, 
Pete Fox 

BN6 

Engineering 

Ross F. Jarvis 

BP23 

Personnel 

Burney Goodwin 

BR6 

Financial Management 

Tom Stanley, Bill Grayburn 

CC4 

Aircraft Operations 

Charles Haines, Vern Swenson, 
A1 King 

CFG 

Flight Crew Support 

Frank Hughes, B. Bahman 

DC 

Preventive Medicine 

Dr. Walter Kemmerer 

DE3 

Biomedical Technology 

Frank Michelli, Dr. Edward Moseley 
Dr. Clarence Jei'nigan 

EA7 

Engineering and Development 

Paul Brandenberger 

EB4 

Information Systems 

Roger Hodgkins 
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Mail 

Code 


Division 


EC1 


Crew Systems 


EE Telemetry and Communications Systems 

EE 2 Telemetry and Communications Systems 

EG7 Guidance and Control 

EL2 Space Environment Test 


ES2 

Structures and Mechanics 

ES34 

Structures and Mechanics 

EX2 

Engineering Analysis 

FC 

Flight Control 

FC1 

Flight Control 

FD4 

Computation and Analysis 

FM13 

Mission Planning and Analysis 

FS 

Flight Support 

FS2 

Flight Support 

FS6 

Flight Support 

HC 

Advanced Program Planning 

JB2 

Program Resources 

JB5 

Program Resources 

JC8 

Contracts 


Persons Interviewed 

Tom Strickler, Edward Smylie, 
Hugh Fleming, Don Perry 

Tom Fleming 

Saverio Guadiano 

Chuck Finch 

David Billingsley, Bill Taylor, 

Jim Anderson 

Ray Nieder, Jim Johnson, Ed Jung 
John Orsag 

Joe Gamble, Ray Nelson 

Bill Platt 

C. S. Howard 

Don Hay, Norris Taylor 

Dick Parten, Mike Collins, 

Jim Grogin 

Maynard Huntley, Sam Ruple 
Kenneth Allen, Larue Burbank 
Jack Garman 

W. L. Davidson, Jim Arnold 
Bob Linberger 

Humboldt Mandell, Bill Roberts, 
Howard Renfro, Garland Bauch, 
Ralph Schomburg, Ronnie Lewis 

Harry Watkins 


Mail 

Code 

Division 

Persons Interviewed 

LV 

Space Shuttle Program 

James Medack 

NA2 

Reliability and Quality Assurance 

Karl Sperber 

NS 

Standards Engineering 

Jim Donnell, Merle Schwartz, 
John Hook 

PP 

Program Control 

Don Haulbrook 

PT3 

Test 

Gallaway Foster, Bill Kelley, 
Jim Gibbons 

TA 

Science and Applications 

Richard Wright 

TF7 

Earth Observations 

Jerry Carney, Sid Whitley, 
Dean Britton 

TJ 

Mapping Sciences Laboratory 

Bob Musgrove, Andrew Patterson 

TL3 - 

Lunar Receiving Laboratory 

Ken Suit, Dave White, Dan Anderson 

TN7 

Lunar and Earth Sciences 

Dr. Jeff Warner 


APPENDIX B - PERSONAL INTERVIEW STRUCTURED QUESTIONS 



CSC 


APPENDIX B - PERSONAL INTERVIEW STRUCTURED QUESTIONS 

1. Does user want terminal and batch capability for the future system? 

a. Batch only 

b. Terminal only 

c. Both 

2. Does user require the capability to update his data on-line? Does he then 
require immediate capability to view the results of his input? 

3. Are there requirements for inter-file interface? 

4. Does the user have a requirement that demands the future system to provide 
the capability such that when data in one file is updated, other files containing 
that item, or items, can be updated automatically? 

5. a. Does U6er require security protection? 

b. What security level is required ? Field, record, or file? 

6. Does user have requirements that demand variable length fields? 

7. Does the user require the capability to have synonyms ? 

8. Does user have requirements that demand use of boolean connections ? 

9. Does user require program to provide any statistical analysis of data? 

10. Does user have requirement for program to provide conditional processing? 

11. Does user requite capability to vary the output report format prior to 
processing, and the ability to display any item or items in a specified file ? 

12. Does user require ability to save a created display from terminal? 

13. Does user require the capability to do a keyword search? 

14. Does user require any graphics capability? 

15. Does user need to publish a document and use program outputs as part or 
all of the source ? 
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16. Does user require any simple arithmetic operations such as +, x, or-j- 

17. Is a hard copy capability needed at the terminal? 

18. Is an audit trail needed ? 

19. Are mathematical function subroutines (trigonometrical, log, exponential, 
square root, etc.) needed by the user applications ? 

20. What terminal devices are wanted for the future system? 

21. What volume of terminal processing per week is expected by the user 
applications ? 

22. How many persons in the user applications will be using the terminal? 

23. What volume of batch processing per week is expected by the user 
applications ? 

24. What response time would be required for reports in batch mode ? 

25. What frequency of usage of program in batch and terminal mode would 
be expected? 

26. Do users have standard input forms they are using for current needs ? 
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Mail 

Code 

Division 

Attendees 

AT 

Advanced Studies 

Sharon Henderson 

BB12 

Institutional Resources and Procure- 
ment 

Bob Soens 

BD22 

Research and Development Systems 

Dave Friis 

BD23 

Research and Development Systems 

Clyde Louirmore 

BF 

Logistics 

Bob Boyd 

BF4 

Logistics 

Bill Bennett 

BF9 

Logistics 

Bill Calhoun, Glen Keith 

BL3 

Photographic Technology Lab 

John Salinas 

BM 

Management Services 

Earl Rubenstein, A1 Bradley 

BM2 

Management Services 

Charles Grant, Harold Davis 

BM24 

Management Services 

Frank Goodson 

BM5 

Management Services 

Roy Magin, Stan Jacobsen, 
Helen Foley 

BN 8 

Engineering 

Carl Romero 

BR6 

Financial Management 

Tom Stanley, Ray Kaufman, 
D. W. Sparkman 

CF6 

Flight Crew Support 

Frank Hughes 

CG 

Crew Procedures 

Jim Lewis 

CG2 

Crew Procedures 

Bill Leverich, Tom Kaiser 


M. E. Dement, Gail Steele, 
John Monroe, John Samouce, 
Bob Hahne 




Mail 

Code 

CG53 

EA7 

EB4 

EB5 

EC1 

EC4 

EC 12 

EE 

EG2 

EG7 

ES2 

ES34 

EX 

FA 

FC1 

FD 

FD3 

FD4 

FD7 


Division 

Crew Procedures 

Engineering and Development 
Information Systems 
Information Systems 
Crew Systems 
Crew Systems 
Crew Systems 

Telemetry and Communications 
Systems 

Guidance and Control 
Guidance and Control 
Structures and Mechanics 
Structures and Mechanics 
Engineering Analysis 
Flight Operations 

Flight Control 
Computation and Analysis 
Computation and Analysis 
Computation and Analysis 
Computation and Analysis 


Attendees 

Mike Gremillion, John Cotter, 
Gene Gentry 

Paul Brandenberger 

Roger Hodgkins 

Emmett Shepard 

Hugh Fleming, Edward Smylie 

Joe Trombley 

Don Perry 

Tom Fleming 

Carey Lively 
Chuck Finch 
Ray Nieder 
John Orsag 
Bill Moseley 

L. C. Dunseith, Bob Driver, 
Bob Ernull, H. W. Tindall, 
John Frere, Jr. 

C. S. Howard, Charlie Harlon 
Ralph Everrett, Don Lloff 

M. Cunningham 

D. Hay, Norris Taylor 
Art Hambleton 


Mail 

Code 

FD81 

FD87 

FM6 

FM13 

FS 

FS4 

FS5 

FS6 

HA 

JB2 

JC2 

ND 

ND3 

ND5 

ND33 

NS 

TF 

TJ 


Attendees 



Division 

Computation and Analysis 
Computation and Analysis 
Mission Planning and Analysis 

Mission Planning and Analysis 

Flight Support 

Flight Support 
Flight Support 
Flight Support 

Advanced Missions Program 
Program Resources 
Contracts 
Quality Assurance 
Quality Assurance 
Quality Assurance 
Quality Assurance 
Standards Engineering 

Earth Observation 
Mapping Sciences Laborator}' 
NASA Headquarters 


Boyd Jackson 
Wilby Ward 

Ernie Fridge, Mary Ann Goodwin, 
Bill Sullivan 

Dick Parten, Mike Collins, 

Jim Grogan, Ray Hischke, 

Dick Simms 

Maynard Huntley, Matt Quinn, ; 
James Stokes, Jerry Milhorn 

Jacqueline Gregan 

Larry Dungan 

Jack Garman, Jim Martin 

Jim Tombei’lin 

Bob Linberger 

Jim Crane 

Ray Heiskala 

Max Callison 

John Fisher, Jack Cohen 

Tom Matuszewski 

Jim Donnell, Merle Schwartz, 

Bill Harvey, Johnny Arnaud 

Edward Zeitler 

Bob Musgrove 

Verl Huff, Gene Lokey 
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APPENDIX D - DELIVERABLE ITEMS HIGHLIGHTS 
D.l STUDY PLAN 

CSC's plan to accomplish all work, including a schedule of agreed upon intermediate 
milestone events and manpower estimates was presented to MSC. The milestone 


schedule is shown below. 
Milestone 

Start Date 

Target 

Completion Date 

Actual 

Completion Date 

Initial Briefing 


8-14-70 

8-7-70 

Data Base Study Plan 

8-3-70 

8-14-70 

8-14-70 

Structured Interviews 

8-15-70 

10-2-70 

9-25-70 

Required Capabilities Analysis 

9-9-70 

10-9-70 

10-1-70 

Identify Candidate Users 

9-21-70 

10-9-70 

10-6-70 

Recommend Pilot Users 

10-1-70 

10-9-70 

10-6-70 

Program Changes to DMS 

10-1-70 

12-1-70 

11-30-70 

Provide DMS Sample Data 

11-1-70 

12-1-70 

11-30-70 

Data Base Structure 
Recommendation 

11-1-70 

12-1-70 

11-30-70 

Midterm Report 


3-1-71 

3-1-71 

Analysis for Future System 

11-9-70 

6-11-71 

6-11-71 

Pilot System & Pilot User 
Recommendation 

1-14-71 

7-9-71 

7-9-71 

Recommend Updates to 
Documentation 

1-4-71 

7-9-71 

7-9-71 

User Indoctrination 

11-9-70 

7-30-71 

7-30-71 

Final Report & Presentation 


7-30-71 

7-29-71 

Executive Summary 


7-3U-71 

7-29-71 

Monthly Progress Report 

1st of each 
Month 

10th of each 
Month 
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D. 2 DESIRABLE CAPABILITIES OF THE PILOT DMS 


CSC, after analyzing MSC data base interests and requirements, determined the 
software and hardware capabilities required by the pilot DMS. CSC organized and 
categorized these required capabilities into a comprehensive report for MSC 
personnel. The report titled, "Desirable Capabilities of the Pilot Data Management 
System for the MSC Data Base, October 1, 1970, " was presented to MSC on 
October 1, 1970. 

D. 3 CANDIDATE DATA FILES AND RECOMMENDED DATA FILES 

After completing initial structured interviews with MSC personnel, CSC analyzed 
each application's data as a candidate for the pilot DMS. From the identified candidate 
MSC users, CSC then recommended for utilization with the pilot DMS those MSC user 
applications which best represented a good cross-section sampling of different types of 
MSC data. 

The report titled, "Candidate Data Files and Recommended Data Files for the MSC 
Data Base, October 6, 1970, " was presented to MSC by CSC. 

D. 4 STUDY PLAN UPDATE 

In concurrence with the technical monitor, the delivery date for the following items 
was changed to December 1, 1970. 

© Required Changes to the Pilot DMS 

• Sample Data for Implementation 

• Data Base Structure Recommendations 
The reasons for the schedule change were: 

• The selection of the pilot DMS by MSC was not made known to CSC 
until October 29, 1970. 

• A four (4) week period following the selection date was required by 
CSC in order to provide MSC with the above three (3) items. 

• This period also included follow-up interviews with the MSC organi- 
zations whose application data had been selected for the pilot DMS. 

D. 5 RECOMMENDED CHANGES TO THE PILOT DMS 

CSC analysts made a comprehensive study of NIPS and HYPERTEXT, the systems 
that together comprised the DMS that was selected for the pilot study. All of the 
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MSC candidate users were interviewed to determine their specific requirements 
for a DMS. Their requirements were then compared to the capabilities pi'ovided 
by NIPS and HYPERTEXT. From this comparison, CSC compiled a list of DMS 
capabilities that are required by the MSC usei's, but were not provided by the pilot 
DMS. 

Recommended changes to the pilot DMS were then organized and categorized by 
the DMS function to which they related. CSC recognized that all of the recommended 
changes to the pilot DMS could not be implemented in the relatively short time period 
allocated for implementation. The recommended changes were therefore listed in the 
order of their importance to the MSC users of the pilot DMS. 

CSC presented to MSC the report titled, "Recommended Changes to the Pilot Data 
Management System, November 30, 1970." 

D. 6 FILE DESCRIPTIONS, SAMPLE DATA, AND DATA STRUCTURE 
RECOMMENDATIONS FOR THE PILOT DMS 

After the pilot user applications had been chosen, sample data was collected that 
could be used as input to the selected application programs. The sample data chosen 
for usage was actual data that had been utilized previously with operational user 
application programs and typical representative data that will be utilized in the newly 
designed user application system. This sample data also contained a cross-section 
of representative data for the pilot user applications that had been selected. 

CSC prepared file descriptions for the MSC user application files that would be in 
the MSC pilot DMS data base, ^he file descriptions explained the record formats of 
the user files as they currently exist for the UNI VAC 1108 computer. Each file 
description contained the following information: field number, field character position, 
number of characters, field picture (numeric or alphanumeric), fieldname, field 
contents and fiel d definition. 

File descriptions were prepared for the following thirteen (13) user application 
files: 

• Labor Distribution 

• Accounting 

• Procurement 497 

o RMD Labor 

• Contract Status Report 

• Budgetary Control 


D-3 



CSC 


• Flight Control Status 

• Standards Engineering Information 

e Capitalized Equipment 

• Graphic Arts 

• Catalog Index 

o Earth Resources Research Data Facility R&D 

• Advanced Spacecraft Cost Analysis 

The file record formats and data were not then available for three (3) of the files 
selected for the pilot DMS. The data base record formats for these files were there 
fore determined and designed by CSC. The file descriptions for these files were 
prepared by CSC as a supplement: 

• Lunar Sample Natural Language Information 

e Skylab Program Operational Data Book (HYPERTEXT) 

• Statements of Work (HYPERTEXT) 

It was necessary to modify the format of the selected user application data on seven 
(7) of the MSC user data files in order to implement the data into the pilot DMS 
data base. 

D. 7 DISPLAY AND OUTPUT FORMATS FOR THE MSC USER FILES 

CSC presented to MSC the document titled, "Display and Output Formats for the 
Pilot DMS User Files, December 11, 1970." This document contained sample 
batch output report pages and report formats for the pilot DMS user files. The 
report formats provided were, for the most part, for typical reports that are 
currently being produced for the MSC user applications. A few of the reports 
were specially formatted by CSC to display all of the data fields contained in the 
user application files. 

D. 8 SUPPLEMENT TO FILE DESCRIPTIONS AND OUTPUT FORMATS 

CSC provided file descriptions, sample data and output report formats for the 
following additional MSC pilot DMS user applications: 

• Lunar Samples Natural Languages Information 
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• Skylab Program Operational Data Book 

• Statements of Work 

CSC presented to MSC the report titled, "Supplement 1 to File Descriptions, 

Sample Data and Output Formats for the Pilot Data Management System, 

December 22, 1970." 

D. 9 MONTHLY PROGRESS REPORTS 

Each month, CSC provided to NASA a technical report that described the status 
of each major task in the data base study project. The progress that was achieved 
within each section of the major tasks during that month was explained in the 
technical report. The manpower hours expended by CSC were shown by calendar 
month and as a cumulative total. 

The monthly progress report also provided the status of the coordination tasks with 
the implementing contractor. Computer time utilized in exercising and evaluating 
the pilot DMS was also shown for each month. 

D. 10 MID-TERM REPORT 

This report described the CSC activities, deliverable and special documents, and 
meetings held during the first seven months of the data base study project. The 
purpose, plans and achievements of the study were also described in the mid-term 
report. 

D. 11 FINAL REPORT 

This report describes the required and desirable functional DMS capabilities for 
the MSC future system. Recommendations concerning implementation of the MSC 
data base and the DMS are also presented. The report also describes the activities 
and the highlights of the entire data base study. 
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APPENDIX E - SPECIAL REPORTS AND DOCUMENTS HIGHLIGHTS 


E. 1 DATA BASE REQUIREMENTS QUESTIONNAIRE 

CSC developed a set of carefully planned questions designed to collect information of uni- 
form quality and to permit the separation of fact from opinion. This Data Base Require- 
ments Questionnaire was sent to all interested MSC groups prior to the intervies. The 
purpose of the questionnaire was to obtain detailed information about the present and future 
planned data processing activities of each group and to determine their data base on-line 
terminal, random access requirements. A copy of the Data Base Requirements Question- 
naire is contained in MSC memorandum 70-FS52-129. 

E. 2 CANDIDATE FILES FOR MSC DATA BASE - PRELIMINARY DRAFT 

CSC formulated a list of potential MSC user applications for the pilot DMS. This MSC user 
application was presented to MSC in the report, "Candidate Files for MSC Data Base, 
Preliminary Draft, September 17, 1970". 

Each MSC user application on the list was analyzed by CSC as to their acceptability as a 
candidate user of the pilot DMS. 

E. 3 SAMPLE QUESTIONS FOR MSC USERS OF PILOT AND FUTURE DMS 

CSC designed 26 questions concerning MSC user requirements for both the pilot DMS and 
the MSC future DMS. The questions were stated in the CSC document, "Sample Questions 
Need Answering From Users For Both Pilot And Future Systems, October 14, 1970, 

Revised November 6, 1970". 

These 26 questions were asked in follow-up interviews by CSC to each of the MSC users 
whose applications were selected for utilization with the pilot DMS. These questions 
covered the important and basic capabilities that should be provided by a Data Management 
System. During the follow-up interviews, the MSC users replied to whether or not each 
of the DMS capabilities was actually required by their application. The questions are shown 
in Appendix B. 

E. 4 MSC DIVISIONS INTERESTED IN THE DATA BASE STUDY 

CSC formulated a list of all MSC divisions that had displayed interest in the data base study. 
CSC presented to MSC the report, "MSC Divisions Interested in the Data Base Study, 

October 16, 1970". In this report, the divisions and mail codes were shown for all the MSC 
user groups that were interviewed by CSC. The report also indicated the divisions and 
mail codes of MSC groups who were interested in the study but had not requested to be inter- 
viewed at that time. 
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E. 5 NIPS/USABAAR DMS CAPABILITIES COMPARISON 

A comparison of NIPS with USABAAR DMS was made in respect to 16 major capabilities 
that should be provided by a data management system. The report, "NIPS/USABAAR 
DMS Capabilities Comparison, October 21, 1970", was given to MSC by CSC. 

E. 6 PILOT DMS PROBLEM AREA ANALYSIS 

In the report, "Recommended Changes to the Pilot Data Management System, November 30, 
1970", CSC outlined 18 necessary changes to oveiwome the system problems and deficiencies 
in NIPS. 

CSC analyzed these NIPS problems and determined ways to circumvent the problems and 
to simulate the DMS capabilities. 

The NIPS problem solutions were described in the report, "Pilot DMS Problem Areas 
Analysis, December 11, 1970", which was presented to MSC by CSC. 

E. 7 ANSWERS TO IBM'S QUESTIONS CONCERNING USER FILE DESCRIPTIONS 

At the December 22, 1970, CSC/IBM Meeting, IBM asked CSC questions concerning the 
MSC user file descriptions and report formats for the pilot DMS. CSC performed the 
necessary research to obtain the required information and then presented to IBM the report 
titled, "Answers to IBM's Questions Concerning User Application File Descriptions and 
Output Reports, January 4, 1971". 

E. 8 PILOT DMS PROBLEM ITEM REPORT 

CSC analysts designed and executed many comprehensive system tests to evaluate the pilot 
DMS. During these system tests, some pilot DMS system problems were encountered by 
CSC. Five of these pilot DMS system problems were described in the report titled, 

"Pilot DMS Problem Item Report, January 4, 1971", which was presented to MSC by CSC. 

E. 9 NIPS DEMONSTRABLE DMS CAPABILITIES 

CSC analysts spent many hours at the IBM 2250 and 2260 terminals executing comprehensive 
system tests that CSC had designed for the pilot DMS. A major purpose of these system 
tests was to evaluate the pilot DMS in relation to the DMS capabilities required by the MSC 
users. The results of these system tests indicated the current status of the DMS capabili- 
ties of NIPS that could be demonstrated. These system test results were highlighted in the 
report titled, "NIPS Demonstrable DMS Capabilities, January 29, 1971", which was 
presented to MSC by CSC. 
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F.l DATA BASE STUDY BRIEFING 

In order to determine MSC requirements for a future automated data management system 
which will support both technical and management personnel, each directorate and division 
of MSC was contacted by CSC and informed about the study, the purpose of the study and 
a general meeting that would be held concerning the study. 

The Data Base Requirements Study general meeting was held August 7, 1970. Mr. Byron 
Huffman of CSC and Mr. B. L. Brady, technical monitor for this study from the Flight 
Support Division, gave a briefing about the data base study and presented the plans, pro- 
cedures and schedules for the study. Mr. Huffman stated that a pilot Data Management 
System (DMS) would be selected that would best meet the requirements of the MSC data 
base users. Mr. Huffman explained that the pilot DMS would probably not satisfy the 
complete data processing requirements of all MSC users. He stated that one purpose of 
this study by CSC is to determine those capabilities required by MSC that could not be 
contained within the scope of a pilot DMS. He also further explained the role of CSC in 
determining from interested users their respective requirements for the future DMS, 
that is, type of data, display formats for report generation, terminal devices required, 
applications, etc. 

A complete description of the August 7 briefing is contained in memorandum 70-FS52-126, 
Participation in a Center-Wide Data Base Requirements Study. 

F.2 CSC/IBM MEETINGS 

Seven (7) Technical meetings between CSC and IBM occurred during December, 1970, 
and January, 1971. The primary purpose of these meetings was to highlight, discuss and 
make plans for resolving any important technical or interface problems concerning the 
pilot DMS. 

Numerous informal meetings and discussions have also occurred between CSC and IBM 
during the data base study. 

F . 3 USABAAR DMS DEMONSTRATION 

The following persons were at Fort Rucker, Alabama, on September 29 and 30, 1970, 
for a demonstration of the USABAAR DMS capabilities: 

• Shirley Hinson (MSC) 

• Jack Adams (IBM) 

• Mike Felix (IBM) 
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e Cleon Smith (IBM) 

© Byron Huffman (CSC) 

F. 4 CANDIDATE AND RECOMMENDED USERS REVIEW MEETING 

A meeting was held with Mr. Jim Stokes, Chief of Flight Software Branch of the Flight 
Support Division, on October 7, 1970. At this meeting, the MSC candidate users and 
recommended users of the pilot DMS were reviewed. 

The major functions performed by these user applications were discussed and the related 
activities between the user applications were pointed out by CSC. 

F. 5 MSC/CSC MEETINGS 

Each week, periodically, CSC reviewed the significant items, work schedules and ex- 
pected completion dates for the tasks in the study with the MSC technical monitor for the 
data base study. 

F. 6 EARTH RESOURCES MEETINGS 

A technical meeting was held on February 25 with Earth Resources and IBM personnel 
in order for CSC to explain the technical procedures for the implementing of the Earth 
Resources Research Data Facility R&D Text and Table Files into the pilot DMS data 
base. CSC described the design, procedures and programs' specifications for correlating 
and combining these files into one composite, structured data file. Mr. Frank Goodson 
indicated that several encode/decode and synonym tables would be required by Earth 
Resources for an expanded terminal capability. A significant effort was expended by 
CSC in developing and designing the best procedures to correlate the data from these 
two files. 

On March 2, 1970, Mr. Frank Goodson demonstrated and explained the present Earth 
Resources catalog, retrieval, and display capabilities and procedures. 

A meeting was held on April 5, 1971, to discuss the plans of the Earth Resources group 
in evaluating and utilizing the terminal capabilities of the Data Management Systems 
available to MSC. 

F. 7 MASSIVE DATA STORAGE PRESENTATION 

A new state-of-the-art technique for providing massive on-line data storage was presented, 
on May 7, 1971, by the AMPEX Corporation. This new system design for data base 
storage is the Terabit Memory System (TBM). The TBM system provides random access 
to 400 billion data bytes which is equivalent to the capacity of 30,000 computer tpes (800 
BPI). TBM utilizes two inch video tape with high data packing and an extremely fast tape 
search speed of 1000 inches per second. 
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G.l CONVERSION OF MSC USER DATA FILES 

The pilot DMS user data was written by the MSC users in UNIVAC 1108 format. In order 
for the data to be entered into the data base for the pilot DMS, the UNIVAC 1108 data files 
had to be converted to an IBM 360 readable format. When the user data files were con- 
verted, however, seven (7) of these files contained binary numeric or signed fields which 
would not convert properly. 

MSC requested CSC to perform the conversion for these data files. CSC was happy to 
comply with this request and designed, wrote and checked out seven (7) COBOL computer 
programs that were required for the data conversion. These data files were then suc- 
cessfully converted by CSC. 

MSC user file description revisions to seven (7) of the pilot DMS user data file descrip- 
tions were designed and documented by CSC analysts. These revisions were necessary 
as a result of the data format changes resulting from the conversion of the user data files 
from UNIVAC 1108 format to IBM 360 format. The actual data files that were converted 
for the IBM 360 computer, and the revised, complete file descriptions were given by 
CSC to the implementing contractor for the following files: 

o Labor Distribution 

• Accounting 

• Procurement 497 

• RMD 

• Contract Status Report 

0 Budgetary Control 

0 Capitalized Equipment 

G. 2 EDITING OF PILOT DMS DATA 

In three (3) of the above files erroneous data existed. Also, some of the financial data 
fields in these files contained amounts exceeding twenty-one (21) million dollars, which 
when processed, caused many system failures in NIPS. CSC, therefore, reconverted 
these files in order to eliminate both the erroneous data and the data that exceeded the 
processing capabilities of NIPS. In order to prevent these system failures, any financial 
data that exceeded one (1) million dollars was eliminated from the user files. 
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The following files were reconverted by CSC: 
o Procurement 497 

e Contract Status Report 

• Budgetary Control 

G. 3 TERMINAL USER CATALOGED ENTRIES 

NIPS did not provide the capability for a terminal user to specify the cataloging (saving) 
of his terminal entry commands. In order to simulate this capability, it was necessary 
to precode some typical MSC terminal user functions and operations and then catalog 
them in the batch mode. 

MSC requested CSC to write these typical MSC user entry functions and operations. CSC 
complied with this request and designed and coded two (2) complete 'programs' of typical 
MSC user terminal entries for each MSC user application of the pilot DMS. 

G.4 PILOT DMS TRAINING SESSIONS 

Special assistance was provided by CSC to the Earth Resources group in structuring 
queries to be used in extracting data from the pilot DMS data base. CSC provided com- 
puter time and terminal assistance to Earth Resources on many occasions to perform 
their information retrieval. One of the queries concerned some coastline mapping data 
requested from the office of the President of the United States. Training sessions were 
also provided to MSC and contractor personnel in utilizing the HYPERTEXT terminal 
data editing and formatting capabilities. 
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APPENDIX H - TERMINAL USER LANGUAGE 


H.l SIMPLICITY OF USE 

The terminal language of the DMS must be oriented toward the non-teehnical users. The 
terminal language must be easy to learn and simple to use. 

When processing specifications are required from a terminal user, the DMS should request 
this information by asking questions of the terminal user. This is called "prompting" the 
user. The terminal user would then enter in the processing specifications for the opera- 
tions he wants performed. A simple conversational mode language would be provided for 
the terminal user. 

Detailed error diagnostics should be displayed by the terminal language whenever the 
terminal user enters invalid information. Simple procedures to correct any user error 
should also be provided so that the user will not be required to reenter the complete query. 

H.2 ENGLISH LANGUAGE ENTRIES 

The terminal user language should normally consist of short English statements. When 
multiple item names are required, the terminal user should be allowed to enter these 
names in any user desired order, separating them by commas. A minimal amount of 
information should be required from the terminal user. 

H.3 TERMINAL USER OPERATIONS 

The terminal user should be able to display any data in the data base that he has been 
authorized to access. He should also be able to create, modify and insert data into data 
sets in the data base for which he has been grated read/write authorization. Unauthorized 
users would be prohibited from performing these operations. 

A user password should be assigned to each terminal user. Associated with each user 
password would be the display and update data authorizations for that user. 

A SORT operation should be available to the terminal user. This would allow him to 
search, retrieve, display and update data in any user specified data sequence. 

A terminal user should be able to save and later reuse any query or file update operation. 

A terminal user should be able to obtain a hardcopy (printed, typewritten, etc. ) of any 
data that was displayed. 

The DMS must therefore provide the capability for a terminal user to perform the follow- 
ing operations: 
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• File Create and Update 

• Sort 

o Catalog/Recall of User Operations 

• Query 

o Display of Data 

o Hardcopy of Displayed Data 

A detailed description of these functional capabilities is provided in Section 3 under Re 
quired DMS Functional Capabilities. 
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LI DMS BATCH PROCESSOR 

• Modification and Expansion Simplicity - The primary requirement for the DMS 
Batch Processor is that the functional modules of the DMS be easy to modify 
and expand. To facilitate making DMS program modifications and enhance- 
ments, the Batch Processor modules should be written in a high level language, 
such as COBOL. High level language programs are considerably easier to 
modify and expand than assembly language programs. This important ad- 
vantage of program modification expansion simplicity provided by a high level 
language is certainly very significant. 

9 Computer Transferability - The DMS must be able to functionally operate on 
other computers by making only minor modifications to the DMS. This capa- 
bility would exist for the Batch Processor if it were written in a high level 
language. Assume for example, that MSC had implemented a DMS utilizing 
the IBM 360 computer and there was a requirement to implement this same 
DMS for the UNIVAC 1108 computer at the Marshall Space Flight Center. 

If a high level language were utilized for the DMS, only minor modifications 
would be required to accomplish this important task. 

9 Batch Processing Efficiency Considerations - The processing performed by 
programs written in a high level language is sometimes slightly less efficient 
than the processing performed by assembly language programs. A certain 
tradeoff to gain important DMS advantages must be offset by a minor dis- 
advantage of a relatively insignficant increase in DMS processing time through 
utilizing a high level language. Normally a high degree of processing efficiency 
is not a critically important requirement for a Batch Processor. The im- 
portant DMS modification, expansion and transferability advantages provided 
by a high level language make the very small difference in the Batch Processor 
run time appear insignificant. 

For these reasons, pure assembly language or even assembly language with 
macros, should be avoided or used sparingly by the Batch Processor. 

1.2 DMS TERMINAL PROCESSOR 

9 Terminal Processing Efficiency Requirement - The primary requirement for 
the DMS terminal processor programs is that the functional modules provide 
an extremely high degree of processing efficiency. This is an absolute 
necessity for the DMS to provide short response times to the many queries 
and update requests from the multiple terminal users. 


1-1 


CSC 


• Interpretive Processing - The terminal processor itself must be able to per- 
form the operations requested by the multiple terminal users. This capability 
eliminates the tremendous amount of lost time and inefficiency which result 
when a terminal processor must create, generate, and then execute temporary 
programs which perform the operations requested by users. 

The terminal processor itself should contain pre-stored functional modules 
which, when invoked by the terminal user entries, perform the requested 
user operations. This capability is called interpretive Processing (see 
Figure 1-1). 

• Macro Terminal Processor Language - The terminal processor program 
routines must also be easy to modify and expand. A high level language, 
although easy to modify and expand, normally provides slightly less pro- 
cessing efficiency, and therefore should not be used for the terminal 
processor pre-stored program routines. Instead, assembly language pro- 
grams containing many well defined macros should be used. A macro is 
simply a series of assembly language program instructions that perform a 
specific processing function. Since macro structures can be standardized 
and repeated many times throughout program routines, program modifica- 
tion and expansion is greatly simplified. If it becomes necessary to transfer 
the DMS to a new computer, only the assembly language portions of the 
terminal processor would have to be rewritten. If processing efficiency is 
not the most critical item in the terminal processor, then it should be written 
in a high level language. 

1.3 GENERATED USER PROGRAMS 

• High Level User Program Language - Only the Batch Processor should 
generate user application programs that will perform the user requested func- 
tions. These generated user application programs must be easy to modify 
and expand by the Batch Processor user. The user programs generated by 
the Batch Processor should, therefore, be written in a high level language, 
such as COBOL. This would allow the Batch Processor user to easily modify 
and expand his programs at two different levels: at the DMS functional 
language level, and the user application program language level. 


1-2 



TERMINAL 

FUNCTIONS 


CSC 





1-3 


Figure 1-1. DMS Terminal Processing 
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The principal data base problem for MSC will be determining which applications data files 
should be structured into the center-wide data base. The main controlling factor will be, 
of course, the amount of on-line data storage available for the MSC data base. The type of 
hardware utilized for the data base storage will decide, to a large extent, the volume of MSC 
data that can be structured into the data base. 

There have been two new recent innovations in utilizing computer hardware other than disks 
or drums for on-line data base storage. The two new hardware data storage hardware sys- 
tem designs are provided by the Terrabit Memory System (of the AMPEX Corporation) and 
the ILLIAC IV System (of the Burroughs Corporation). 

J. 1 TERRABIT MEMORY SYSTEM (TBM) 

Up to 400 billion data bytes can be stored on-line for rapid access by terminal users. This 
data storage is equivalent to the data storage provided by 1500 IBM 2314 disk drives. The 
TBM system utilizes standard two inch wide video tape. The data is recorded in blocks on 
the tape, each block being identified by a unique address. Each TBM reel can contain 5. 5 
billion data bytes, which is equivalent to 500 computer tapes. 

Rapid access to any records on the tapes is achieved by searching the record block identi- 
fiers at tape speeds of one-thousand (1000) inches per second, forward and backward. This 
high tape search speed together with high data packing density and six simultaneous tape 
accesses make possible the searching of the equivalent of sixty (60) conventional full com- 
puter tapes in one second. 

There are also other technical features of the TBM. There is extensive built-in file pro- 
tection and data security. TBM is modular; it is expandable in 11 billion byte increments. 
There can be six simultaneous data transfers and searches. There is dynamic device 
reconfiguration and multipath access. System control and hardware fault diagnosis and 
isolation is also provided by internal computers. Read/write error detection and correc- 
tion logic is provided. Update in place and selective block (record) erase are other im- 
portant features. An internal data file to file copy is provided. Two output files can be 
written simultaneously. TBM can be utilized in a stand alone environment or it can be 
interfaced with other computers. All these features can be obtained for a cost as low as 
one ten-thousandth (. 0001) of a cent per bit. 

There are many advantages provided by the TBM system. It is an economical approach to 
data base consolidation into a single integrated and meaningful structure. TBM's rapid 
file maintenance capabilities and high throughput have, on occasion, reduced application 
processing time from more than five hours to a few minutes. With TBM's versatile 
access methods, only the desired records need be sent to the host computer for processing. 
A dynamic multilevel priority processing capability, together with many simultaneous 
random accesses to multiple data files make TBM a powerful element of on-line, real-time 
data communication systems. Protection against accidental overwriting is provided through 
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read only interlocks. Data access protection is implemented through user oriented codes 
associated with individual blocks or entire files. TBM provides an economical means of 
keeping several generations of files on-line. TBM greatly facilitates job scheduling since 
tapes and disk packs do not have to be retrieved and mounted - the data is always there. 

High reliability is achieved through extensive hardware component redundancy, multipath 
access and dynamic device reconfiguration. 

For further information concerning TBM, the AMPEX Corporation should be contacted. 

J. 2 ILLIAC IV 

One example of the expanding technology in the computer industry today is the ILLIAC IV 
computer. New techniques of memory storage, utilizing laser beams, give ILLIAC IV the 
capacity to store one trillion bits of information in a comparatively small space. One would 
need about 250, 000 standard magnetic tapes to maintain an equivalent amount of data. This 
new memory storage is called Archival Memory. It is a new high-capacity secondary 
memory, developed by the Precision Instrument Company. The beam from an argon laser 
records binary data by burning microscopic holes in a thin film of metal coated on a strip 
of polyester sheet, which is carried by a rotating drum. Each data strip can store some 
2. 9 billion bits, the equivalent of 625 reels of standard magnetic tape in less than 1% of the 
volume. The "strip file" provides storage for 400 such data strips containing more than 
a trillion bits. The time to locate data stored on any one of the 400 strips is about five 
seconds. Within the same data strip data can be located in 200 miliseconds. The read- 
and-record rate is four million bits a second. 

This machine will be capable of executing between 1000, 000, 000 and 200, 000, 000 individual 
commands per second. Unlike its three predecessors (ILLIAC I, II AND III) and all com- 
puters now on the market, which solve problems by a series of sequential steps, ILLIAC 
IV is designed to perform as many as 64 computations simultaneously. For such a com- 
puting structure to be utilized efficiently the problem must be amenable to parallel, rather 
than sequential, processing. In actuality, problems of this kind constitute a considerable 
part of the total computational spectrum, ranging from payroll calculations to linear pro- 
gramming to models of the general circulation of the atmosphere for use in weather predic- 
tion. For example, a typical linear-programming problem that might occupy a large 
present-generation computer for six to eight hours should be solvable by ILLIAC IV in less 
than two minutes, a time reduction of at least 200 to 1. These problems could present 
over 4,000 constraints (the defined conditions or parameters of the situation) and 10, 000 
variables. 

The key factor in facilitating the handling of the problem, of course, is solving many parts 
of the problem at the same time - up to 64 simultaneous computations on 64 "slave" or 
auxiliary processing units - rather than only solving one part of the problem at a time. 

The ultimate limitation of the operating speed of a computer designed to operate sequentially 
is the speed with which a signal can be propagated through an electrical conductor. In 
practice this is somewhat less than the speed of light, which takes one nanosecond (one 
billionth of a second) to travel about one foot. Although integrated circuits containing 
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transistors packed together with a density ranging from several hundred to several thousand 
per square inch have helped greatly to reduce the length of interconnections inside computers, 
designers have been increasingly aware that new kinds of logical organization are needed to 
penetrate the barrier set by the speed of light. ILLIAC IV circumvents this problem by para- 
llel processing. 

ILLIAC IV can diagnose its own problems. In a system containing more than six million 
components one can expect a component or a connection to fail every few hours. For this 
reason much attention has been devoted to testing and diagnostic procedures. Each of the 
64 processing units will be subjected regularly to an extensive library of automatic tests. 

If a unit should fail one of these tests, it can be quickly unplugged and replaced by a spare, 
with only a brief loss of operating time. When the defective unit has been taken out of service, 
the precise cause of the failure will be determined by a separate diagnostic computer. Once 
the fault has been found and repaired, the unit will be returned to the inventory of spares. 

It took two medium sized computers working almost full time for two years to help design 
the meticulous micro-circuitry of the hardware and prepare diagnostic programs for the 
software. Another computer is wholly devoted to talking to ILLIAC IV. "Noboby" else can. 
This general purpose computer is responsible for translating the many languages of the 
computer programmers into the hardware-determined language of the big machine itself. 
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K. 1 ACCESS KEY 

The sequencing item or record key that determines the placement of each record in the data 
file. The access key is used when reading or writing any record in the file. 

K. 2 ACCESS TIME 

The time interval between the instant at which data is requested to be read or written and 
the instant the device actually begins the data transfer operation. 

K. 3 ANSWER SET 

Records which are created as the result of terminal user selection criteria in queries. 
These records are then displayed to the terminal user. 

K. 4 APPLICATION PROGRAM 

A computer program which performs one or more basic functions such as file update, re- 
port generation, data editing, sorting, etc. 

K. 5 APPLICATION SYSTEM 

Application programs combined into a logical series or organization of processing steps to 
provide a major functional processing system. An application system normally contains a 
series of programs to edit input data, update data files, extract data from data files, and 
generate reports. 

K. 6 AUDIT TRAIL 

The saving of all modifications made to data in the data base. It could include the saving 
of the updated data base records before and after modifications are made. 

K. 7 BATCH PROCESSING 

The scheduling and processing of applications that do not require real-time or immediate 
computer processing. Normally applications which do not require quick answers or which 
process a large amount of input data are run as batch jobs. 

K. 8 CENTRAL PROCESSING UNIT (CPU) 

The computer hardware unit in which the actual execution and processing of computer pro- 
grams takes place. 



K. 9 CRT 

The abbreviation for cathode ray tube. A CRT is used in many terminal devices for dis- 
playing user specified data items. 

K.10 DATA 

% 

Items of information. 

K. 11 DATABASE 

A collection of one or more data files. 

K. 12 DATA ITEM (FIELD) 

A piece of information in a data file. Normally this is the smallest organization of data in 
a data file. 

K. 13 DATA MANAGEMENT SUPERVISOR 

A set of interrelated computer programs which provide capabilities such as data descrip- 
tion, creation, maintenance, sorting, retrieval and reporting. 

K. 14 DATA RECORD 

A logical organization of related data items which describe a particular activity such as pro- 
curement. A data file consists of a series of data records. 

K. 15 DATA RETRIEVAL 

The reading of data records from the data base into the computer's core storage for pro- 
cessing. Data is normally retrieved based upon conditions specified by a user's query. 

K. 16 DATA SECURITY 

Data protection provided by the DMS to prevent unauthorized read/write operations on sen- 
sitive or classified data. 

K. 17 DATA SET (DATA FILE) 

A series of data records containing information concerning a particular application of activity. 
A payroll data set is a collection of individual employee payroll records. 

K. 18 DATA STRUCTURING 

The physical arrangement of data so that it can be identified, created, updated, and 
retrieved. 
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K. 19 DATA VALIDATION 
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The checking of data items against specifications to ensure the data is acceptable. If an 
item does not meet the specifications, it is rejected. 

K. 20 DIAGNOSTIC 

A meaningful; reported comment regarding a problem that was encountered during pro- 
cessing. 

K. 21 DIRECT ACCESS STORAGE DEVICE (DASD) 

A hardware device such as magnetic disk and drum which allow any data record to be directly 
accessed. It can be contrasted with the hardware devices such as tape which permit only 
sequential searches for data records. 

K. 22 DMS CAPABILITIES 

The functional operations provided to users by a DMS. This includes functions such as 
data editing and updating, sorting, report formatting and report generation. 

K. 23 DYNAMIC DATA FILE 

A data file whose volume (number of records) is constantly increasing. 

K. 24 FILE CREATION 

The initial writing of a series of data records to form a data file. 

K. 25 FUNCTIONAL MODULES 

Program logic modules which perform functional operations such as file description, file 
creation and maintenance, sorting, retrieving, report formatting and generation. 

K. 26 HARDWARE 

The computer with all its functional units and devices, such as central processing units, 
terminals, tape drives, core storage, printer, etc. 

K. 27 KEYWORD 

Keywords associate data records in a file with particular subjects or categories. Keywords 
are used for searching a data file for documents related to a particular subject, category, 
author, etc. 
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K. 28 LANGUAGE 

A means by which a user communicates with the DMS and the computer. A terminal user 
language and a batch processing language are provided by the DMS. 

K. 29 MULTIPLE FILE ACCESS 

The capability to retrieve data from many data files in the same query. 

K. 30 MULTIPLE FILE UPDATE 

The capability to automatically update a data item in all files in which it exists whenever 
an update of the item occurs in any file. 

K. 31 OPERATING SYSTEM 

The resident computer system which actually performs the basic functions of hardware de- 
vice input/output (as directed by the DMS or application program) and coordinates the exe- 
cution of the programs in the central processing unit. 

K. 32 QUERY 

The retrieval of data from the data base that satisfies the terminal user's specified search 
criteria. The retrieval data is then normally displayed on a terminal CRT and/or printed 
on a hard copy device. 

K. 33 REAL-TIME PROCESSING 

The immediate processing of input data and user requests at the time they are received. 
This capability provided by a DMS allows terminal users to rapidly query and update data 
in the data base. 

K. 34 REPORT FORMATTING 

The arranging and editing of data items that will be displayed on a terminal CRT or printed 
in a hard copy report. 

K. 35 RESPONSE TIME 

The time interval between the start of a terminal functional operation and the actual com- 
pletion of the operation or when the specified data is made available at the terminal. 

K. 36 RUN 

The execution and processing of one or more computer programs. 
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K. 37 SEARCH 

To examine records of a file or data item within records for desired values of specified 
conditions. 

K. 38 SOFTWARE 

The combination of the computer's operating system, DMS, and application programs 
working jointly to perform the desired functional data processing tasks. 

K. 39 SORT 

The sequencing of the records in a data file by using specified data items to control the 
placement of records in the file. 

K. 40 STANDARDIZED PROGRAM ROUTINE 

Program modules that for any particular functional operation contain the same basic pro- 
cessing logic. The only processing differences in these routines result from user speci- 
fied parameters. 

K. 41 STATIC DATA FILE 

A data file whose volume (number of records) remains approximately the same. 

K. 42 SYNONYM 

Another data name that can be used in referencing a particular data item. 

K. 43 TERMINAL 

A hardware device used for real-time querying and update of data in the data base. 

K. 44 TERMINAL PROCESSING 

The querying and update of data in the data base as specified by a terminal user. 

K. 45 VARIABLE LENGTH DATA 

Data items which can vary in length within the records of a file. Some examples are 
narrative data, comments and descriptions, etc. 

K. 46 VECTOR GENERATION 

The capability of a terminal device to generate vertical, horizontal, and diagonal lines 
for drawings, graphs and models. 
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